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-03-14 03:05:21 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel, 2016-12-15, Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 20 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE such as for Internet of Things applications. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques. "Transmission of IPv6 over MS/TP Networks", Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson, 2017-03-13, Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. "Transmission of IPv6 Packets over Near Field Communication", Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi, 2017-03-07, 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-01-11, 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 higher speed backbone federates multiple wireless links to form a large MultiLink Subnet. Backbone Routers acting as Layer-3 Access Point route packets to registered nodes, where an classical Layer-2 Access Point would bridge. Conversely, wireless nodes register or are proxy-registered to the Backbone Router to setup routing 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-03-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, 2016-11-13, This document defines an extension to 6LoWPAN Neighbor Discovery. This extension is designed for low-power and lossy network environments and it supports multi-hop operation. Nodes supporting this extension compute a Cryptographically Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID (Crypto-ID) uniquely identifies the owner of the Registered Address. It is used in place of the EUI-64 address that is specified in RFC 6775. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the state information of the Registered Address in the 6LR and 6LBR. "IPv6 over Constrained Node Networks(6lo) Applicability & Use cases", Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, 2017-03-13, This document describes the applicability of IPv6 over constrained node networks (6lo) and use cases. It describes the practical deployment scenarios of 6lo technologies with the consideration of 6lo link layer technologies and identifies the requirements. 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, LTE MTC, PLC (IEEE 1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node networks for typical services. Based on these link layer technologies, IPv6 over networks of resource-constrained nodes has various and practical use cases. To efficiently implement typical services, the applicability and consideration of several design space dimensions are described. "An Update to 6LoWPAN ND", Pascal Thubert, Erik Nordmark, Samita Chakrabarti, 2017-01-11, This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, and provide enhancements to the registration capabilities, in particular for the registration to a backbone router for proxy ND operations. IPv6 Maintenance (6man) ----------------------- "IPv6 Neighbor Discovery Optional RS/RA Refresh", Erik Nordmark, Andrew Yourtchenko, Suresh Krishnan, 2016-10-31, IPv6 Neighbor Discovery relies on periodic multicast Router Advertisement messages to update timer values and to distribute new information (such as new prefixes) to hosts. On some links the use of periodic multicast messages to all host becomes expensive, and in some cases it results in hosts waking up frequently. Many implementations of RFC 4861 also use multicast for solicited Router Advertisement messages, even though that behavior is optional. This specification provides an optional mechanism for hosts and routers where instead of periodic multicast Router Advertisements the hosts are instructed (by the routers) to use Router Solicitations to request refreshed Router Advertisements. This mechanism is enabled by configuring the router to include a new option in the Router Advertisement in order to allow the network administrator to choose host behavior based on whether periodic multicast are more efficient on their link or not. The routers can also tell whether the hosts are capable of the new behavior through a new flag in the Router Solicitations. "IPv6 Router Advertisement Options for DNS Configuration", Jaehoon Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli, 2017-02-08, This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. "Republishing the IPV6-specific MIB modules as obsolete", Bill Fenner, 2016-11-13, In 2005, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB and IPV6-UDP-MIB modules, for the purpose of updating MIB module repositories. "Internet Protocol, Version 6 (IPv6) Specification", Steve Deering, Robert Hinden, 2016-11-15, This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 "Support for adjustable maximum router lifetimes per-link", Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko, 2017-03-09, 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-03-13, 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, Stephen <>, 2017-01-31, 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". "Path MTU Discovery for IP version 6", Jack <>, Stephen <>, Jeffrey <>, Robert Hinden, 2017-01-31, This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. 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-01-27, 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, 2016-12-16, 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. "Minimal 6TiSCH Configuration", Xavier Vilajosana, Kris Pister, Thomas Watteyne, 2017-02-20, This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Network. This minimal mode of operation specifies the baseline set of protocols that need to be supported, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap, and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices. "6top Protocol (6P)", Qin Wang, Xavier Vilajosana, 2016-10-31, This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes in a 6TiSCH network to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.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. Different SFs are expected to be defined in future companion specifications. "6TiSCH 6top Scheduling Function Zero (SF0)", Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura, 2017-03-13, This document defines a Scheduling Function called "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of allocated 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. "Minimal Security Framework for 6TiSCH", Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson, 2017-03-12, 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 Secure Join protocol", Michael Richardson, 2017-02-25, 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]. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Goeran Selander, Carsten Bormann, 2017-03-06, Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. "Authentication and Authorization for Constrained Environments (ACE)", Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2017-03-13, This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. "CBOR Web Token (CWT)", Michael Jones, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2017-03-02, CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. 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. Automated Certificate Management Environment (acme) --------------------------------------------------- "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, James Kasten, 2017-03-13, 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-02-04, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Multi-Cost ALTO", Sabine Randriamasy, Wendy Roome, Nico Schwan, 2017-03-10, The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. An ALTO Server may offer a variety of cost metrics, based on latency,bandwidth, hop count, jitter, or whatever else the ALTO Server deems useful. For example, when downloading a file that is mirrored on several sites, a user application may consider more than one metric, perhaps trading bandwidth for latency to determine the most efficient mirror site. While the base ALTO Protocol allows an ALTO Client to use more than one cost metric, to do so, the Client must request each metric separately. This document defines a new service that allows a Client to retrieve several cost metrics with one request, which is considerably more efficient. In addition, this document extends the ALTO constraint tests to allow a user to specify an arbitrary logical combination of tests on several cost metrics. "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2017-03-12, The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information to client applications so that clients may make informed decisions. To that end, an ALTO Server provides Network and Cost Maps. Using those maps, an ALTO Client can determine the costs between endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to those maps, other than by periodically re-fetching them. Because the maps may be large (potentially tens of megabytes), and because only parts of the maps may change frequently (especially Cost Maps), that can be extremely inefficient. Therefore this document presents a mechanism to allow an ALTO Server to provide updates to ALTO Clients. Updates can be both immediate, in that the server can send updates as soon as they are available, and incremental, in that if only a small section of a map changes, the server can send just the changes. "ALTO Cost Calendar", Sabine Randriamasy, Yang Yang, Wenson Wu, Deng Lingli, Nico Schwan, 2017-02-13, 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-03-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 offers 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. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian Carpenter, Bing Liu, 2017-03-09, This document establishes requirements for a signaling protocol that enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. "An Autonomic Control Plane", Michael Behringer, Toerless Eckert, Steinthor Bjarnason, 2017-01-12, Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "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 communications over a network that is not configured, or mis-configured. "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen, 2017-03-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 the Internet, 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-03-13, 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-03-09, This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. 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-02-07, OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either 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). to provide stable and secure connectivity for those OAM processes. "Voucher Profile for Bootstrapping Protocols", Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, 2017-03-13, 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 been signed using a PKCS#7 structure. The voucher artifact is generated by the pledge's manufacture or delegate (i.e. the MASA). 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-03-12, 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) ------------------------------------- "Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)", Kenneth Murchison, 2017-01-13, This document defines an update to the HTTP Prefer header field [RFC7240] to specify how it can be used by a WebDAV client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth- noroot" preference. "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", Henk Birkholz, Christoph Vigano, Carsten Bormann, 2017-03-13, 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. "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. "Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation", Marianne Mohali, Mary Barnes, 2017-01-30, RFC4458 (SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document creates a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC4458, for using the "cause" URI parameter within the History-Info header field since this use is mandatory in some IP networks' implementations. This document updates RFC4458. "Comprehensive Core Rules and References for ABNF", Sean Leonard, 2017-03-13, This document extends the base definition of ABNF (Augmented Backus- Naur Form) to include a reference syntax, along with core rules that provide comprehensive support for certain symbols related to ASCII. "IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service", Christer Holmberg, Joergen Axell, 2017-01-19, This document creates an additional Session Initiation Protocol (SIP) Resource-Priority namespace to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places this namespace in the IANA registry. "Regular Expressions for Internet Mail", Sean Leonard, Joe Hildebrand, Tony Hansen, 2017-03-13, Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms. "Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan Bosch, 2016-10-10, 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. "Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)", Julien Elie, 2017-02-07, This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. If approved, this document updates RFC 4642. "IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST", Kenneth Murchison, Bron Gondwana, 2016-11-22, 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, 2016-12-08, This document specifies a Uniform Resource Identifier (URI) for Persistent Web IDentifiers to web archives using the 'pwid' scheme name. The purpose of the standard is to support general, global, sustainable, humanly readable and technology agnostic persistent web references that are not sufficiently covered by existing web reference practices. Since only archived web can reach a degree of persistency. The 'pwid' URI primarily aim at references into web archives. "Variant Rules", Asmus Freytag, 2017-03-13, Rules for validating identifier labels and alternate representations of those labels (variants) are known as "Label Generation Rulesets" (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways of designing Label Generation Rulesets (LGRs) that support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well-behaved in the presence of variants. The design decisions can then be expressed using the an XML representation of LGRs that is defined in RFC7940. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon, 2015-11-25, This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. "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. "The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions", Woo-Hwan Kim, Jungkeun Lee, Je Park, Daesung Kwon, Dong-Chan Kim, 2016-11-13, This document defines SRTP crypto suites based on the ARIA block cipher algorithm for use with the Session Description Protocol (SDP) security descriptions. "A General Mechanism for RTP Header Extensions", Roni Even, David Singer, HariKishan Desineni, 2017-02-27, 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. "Frame Marking RTP Header Extension", Espen Berger, Suhas Nandakumar, Mo Zanaty, 2017-03-13, This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. "RTP Stream Identifier Source Description (SDES)", Adam Roach, Suhas Nandakumar, Peter Thatcher, 2016-10-06, This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. Babel routing protocol (babel) ------------------------------ "Applicability of the Babel routing protocol", Juliusz Chroboczek, 2017-01-05, This document describes some application areas where the Babel routing protocol (RFC 6126) has been found to be useful. "The Babel Routing Protocol", Juliusz Chroboczek, 2017-01-31, Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. BGP Enabled ServiceS (bess) --------------------------- "BGP-Signaled End-System IP/VPNs", Stuart Mackie, Luyuan Fang, Nischal Sheth, Maria Napierala, Nabil Bitar, 2016-12-15, This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs is used and extended via the XMPP protocol to provide a Virtual Network service to end-systems (hosts). These end-systems may be used to provide network services or may host end-user applications. "L2L3 VPN Multicast MIB", Zhaohui Zhang, Hiroshi Tsunoda, 2017-02-20, 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 common managed objects used by other MIB modules which are designed for monitoring and/or configuring both Layer 2 and Layer 3 Virtual Private Networks (VPN) that support multicast. "MPLS/BGP Layer 3 VPN Multicast Management Information Base", Zhaohui Zhang, Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain, Hiroshi Tsunoda, 2017-03-01, 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 router. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Ali Sajassi, Keyur Patel, Aldrin Isaac, 2017-03-13, 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 will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. "A Network Virtualization Overlay Solution using EVPN", Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx, 2016-11-30, This document describes how Ethernet VPN (EVPN) [RFC7432] 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. "Integrated Routing and Bridging in EVPN", Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan, Lucy Yong, 2017-02-10, EVPN provides an extensible and flexible multi-homing VPN solution for intra-subnet connectivity among hosts/VMs over an MPLS/IP network. However, there are scenarios in which inter-subnet forwarding among hosts/VMs across different IP subnets is required, while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. "IP Prefix Advertisement in EVPN", Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi, 2017-02-12, EVPN provides a flexible control plane that allows intra-subnet connectivity in an IP/MPLS and/or an NVO-based network. In NVO 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 may not support their own 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. "VPWS support in EVPN", Sami Boutros, Ali Sajassi, Samer Salam, John Drake, Jorge Rabadan, 2017-03-12, This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. "E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, John Drake, Jim Uttaro, Sami Boutros, Jorge Rabadan, 2017-01-13, 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 proposed in and RFC called "A Framework for E-Tree Service over MPLS Network". This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates that RFC accordingly. "VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, Samir Thoria, tsingh@juniper.net, John Drake, Jeff Tantsura, 2016-10-21, This document describes how Ethernet VPN (E-VPN) technology can be used to interconnect VXLAN or NVGRE networks over an MPLS/IP network. This is to provide intra-subnet connectivity at Layer 2 and control- plane separation among the interconnected VXLAN or NVGRE networks. The scope of the learning of host MAC addresses in VXLAN or NVGRE network is limited to data plane learning in this document. "IGMP and MLD Proxy for EVPN", Ali Sajassi, Samir Thoria, Keyur Patel, Derek Yeung, John Drake, Wen Lin, 2016-10-31, Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs. "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler, 2017-03-13, This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertized toward a standby upstream PE. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2017-01-09, 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-02-15, 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, 2016-10-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 (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, 2016-10-07, 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, 2016-10-31, This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. "Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang, 2016-12-12, 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 EVPN", Patrice Brissette, Ali Sajassi, Himanshu Shah, Zhenbin Li, Kishore Tiruveedhula, Iftekhar Hussain, Jorge Rabadan, 2017-03-13, This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. Any "add-on" features such as EVPN IRB, EVPN overlay, etc. are for future investigation. This document mainly focuses on EVPN and Ethernet-Segment instance framework. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, Ing-Wher Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula, 2017-03-13, 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. "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, 2016-09-13, 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, 2016-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. "BGP Control Plane for NSH SFC", Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil, 2017-02-13, This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header. This document adopts the SFC architecture described in RFC 7665. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, 2016-12-14, This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. 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, 2016-09-21, 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. "Session Description Protocol (SDP) WebSocket Connection URI Attribute", Ram R, Gonzalo Salgueiro, 2017-02-06, The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, 2016-10-12, 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, 2016-10-13, 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, Juniper Networks, Mahesh Jethanandani, Gregory Mirsky, 2017-03-10, 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-01-03, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD [RFC5880]. Bit Indexed Explicit Replication (bier) --------------------------------------- "Multicast using Bit Index Explicit Replication", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Tony Przygienda, Sam Aldrin, 2016-10-28, 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. 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-03-13, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the 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, 2016-12-09, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. 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-01-10, 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-01-08, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a 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, 2016-09-22, 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-01-17, 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-01-17, This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Tony Przygienda, Andrew Dolganow, 2017-01-17, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola, 2017-01-24, This document describes a passive 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-01-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 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-01-21, 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-01-18, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information. Benchmarking Methodology (bmwg) ------------------------------- "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", Al Morton, 2016-08-14, Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general purpose hardware. See the new version history section for updates. "Data Center Benchmarking Terminology", Lucien Avramov, jhrapp@gmail.com, 2016-12-30, The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network switches and routers in the data center. "Data Center Benchmarking Methodology", Lucien Avramov, jhrapp@gmail.com, 2016-12-30, The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. "Benchmarking The Neighbor Discovery Protocol", William Cerveny, Ron Bonica, Reji Thomas, 2017-03-02, This document provides benchmarking procedures for Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured. "Benchmarking Methodology for IPv6 Transition Technologies", Marius Georgescu, Liviu Pislaru, Gabor Lencse, 2017-03-01, There are benchmarking methodologies addressing the performance of network interconnect devices that are IPv4- or IPv6-capable, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be very well tested using the recommendations of RFC2544 and RFC5180. The methodology also includes a tentative metric for benchmarking load scalability. "Terminology for Benchmarking SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2017-01-07, 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-01-07, 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 Virtual Switches in OPNFV", Maryam Tahhan, Billy O'Mahony, Al Morton, 2016-10-14, This memo describes the progress of the Open Platform for NFV (OPNFV) project on virtual switch performance "VSWITCHPERF". This project intends to build on the current and completed work of the Benchmarking Methodology Working Group in IETF, by referencing existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo begins to describe the additional considerations when virtual switches are implemented in general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure. Calendaring Extensions (calext) ------------------------------- "Support for iCalendar Relationships", Michael Douglass, 2017-02-10, This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, STRUCTURED-CATEGORY and REFID to allow better linking and grouping of iCalendar components and related data. "Event Publishing Extensions to iCalendar", Michael Douglass, 2017-03-05, 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, Kenneth Murchison, 2017-03-13, 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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Link Management Protocol Extensions for Grid Property Negotiation", Qilei Wang, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang, 2016-09-22, ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which provides a new tool that operators can implement to provide a higher degree of network optimization than is possible with fixed-grid systems. This document describes the extensions to the Link Management Protocol (LMP) to negotiate link grid property between the adjacent DWDM nodes before the link is brought up. "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-03-13, 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-02-15, 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-02-13, 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, 2017-03-13, To ensure an efficient data transport, meeting the requirements requested by today's IP-services the control and management of DWDM interfaces is a precondition for enhanced multilayer networking and for an further automation of network provisioning and operation. This document describes use cases and requirements 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, 2017-02-21, 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, 2016-12-18, 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. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent Leung, sorber@apache.org, Matthew Miller, 2016-10-04, This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing method as a JSON Web Token (JWT) [RFC7519] profile. The proposed URI signing method specifies the information needed to be included in the URI to transmit the signed JWT as well as the claims needed by the signed JWT to authorize a UA. The mechanism described can be used both in CDNI and single CDN scenarios. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) ------------------------------------------------------------------------ "Extensible Binary Meta Language", Steve <>, Dave <>, Moritz <>, 2017-02-26, 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. Crypto Forum (cfrg) ------------------- "Hash-Based Signatures", David McGrew, Michael Curcio, Scott Fluhrer, 2017-03-05, 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-01-16, 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 password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line 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 off-line 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). "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Aziz Mohaisen, 2017-03-10, This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand attacks using quantum computers. "Requirements for PAKE schemes", Joern-Marc Schmidt, 2017-02-08, Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG). "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2016-09-22, 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-02-23, 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. "Re-keying Mechanisms for Symmetric Keys", Stanislav Smyshlyaev, Russ Housley, Mihir Bellare, Evgeny Alekseev, Smyshliaeva Ekaterina, 2017-03-07, This specification contains a description of a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms that can be used with such modes of operations as CTR, GCM, CBC, CFB, OFB and OMAC. 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. "CLUE Signaling", Paul Kyzivat, Lennard Xiao, Christian Groves, Robert Hansen, 2017-03-13, 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-02-23, 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, 2016-12-19, This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716]. "Ambisonics in an Ogg Opus Container", Michael Graczyk, Jan Skoglund, 2016-11-21, This document defines an extension to the Ogg format to encapsulate ambisonics coded using the Opus audio codec. Constrained RESTful Environments (core) --------------------------------------- "Representing CoRE Formats in JSON and CBOR", Kepeng Li, Akbar Rahman, Carsten Bormann, 2017-03-13, 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, 2017-03-13, 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, 2017-03-13, 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, Paramter, 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 note: The git repository for the draft is found at https://github.com/core-wg/interfaces_ _Editor's note: Two open issues are proposals for: Removing the binding interface in favour of the link list interface. Changing "rel" type from one attribute to two to indicate src and destination._ "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Carsten Bormann, Simon Lemay, Hannes Tschofenig, Klaus Hartke, Bill Silverajan, Brian Raymor, 2017-03-06, 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 [RFC7641] for use with these transports. "Media Types for Sensor Measurement Lists (SenML)", Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keranen, Carsten Bormann, 2017-03-13, 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-02-07, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. "Patch and Fetch Methods for Constrained Application Protocol (CoAP)", Peter Van der Stok, Carsten Bormann, Anuj Sehgal, 2016-11-13, The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. This specification defines the new CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update parts of a resource. "Dynamic Resource Linking for Constrained RESTful Environments", Zach Shelby, Matthieu Vial, Michael Koster, Christian Groves, 2017-03-13, 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 of CoAP (OSCOAP)", Goeran Selander, John Mattsson, Francesca Palombini, Ludwig Seitz, 2017-03-13, This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document. "CoAP Simple Congestion Control/Advanced", Carsten Bormann, August Betzler, Carles Gomez, Ilker Demirkol, 2017-03-13, The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. It is making use of input from simulations and experiments in real networks. "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2017-03-13, 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)", Abhinav Somaraju, Michel Veillette, Alexander Pelov, Randy Turner, Ana Minaburo, 2016-10-31, YANG Schema Item iDentifiers (SID) are used to identify different YANG items using a numeric identifier. This document defines 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", Peter Van der Stok, Andy Bierman, Michel Veillette, Alexander Pelov, 2017-01-26, 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 data 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. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE)", Jim Schaad, 2016-11-22, Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", Mark Baushke, 2016-09-20, This document adds recommendations for adoption of ssh-curves from the [I-D.ietf-curdle-ssh-curves] and new-modp from the [I-D.ietf-curdle-ssh-modp-dh-sha2], and deprecates some previously specified Key Exchange Method algorithm names for the Secure Shell (SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying the set key exchange algorithms that currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange methods use the SHA-2 family of hashes. "Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", denis bider, 2017-02-27, This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. "Extension Negotiation in Secure Shell (SSH)", denis bider, 2017-02-27, This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed key exchange. "Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure", Simon Josefsson, Jim Schaad, 2016-11-23, 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, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. "Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)", Russ Housley, 2017-01-26, 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-03-06, This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 2017-02-13, This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. 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, 2016-10-03, 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 wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. "Deterministic Networking Problem Statement", Norman Finn, Pascal Thubert, 2016-09-28, 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-03-13, 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. "DetNet Data Plane Protocol and Solution Alternatives", Jouni Korhonen, Janos Farkas, Gregory Mirsky, Pascal Thubert, Zhuangyan, Lou Berger, 2016-10-01, This document identifies existing IP and MPLS, and other encapsulations that run over IP and/or MPLS data plane technologies that can be considered as the base line solution for deterministic networking data plane definition. Dynamic Host Configuration (dhc) -------------------------------- "Secure DHCPv6", Lishan Li, Sheng Jiang, Yong Cui, Tatuya Jinmei, Ted Lemon, Dacheng Zhang, 2017-02-21, DHCPv6 includes no deployable security mechanism that can protect end-to-end communication between DHCP clients and servers. This document describes a mechanism for using public key cryptography to provide such security. The mechanism provides encryption in all cases, and can be used for authentication based on pre-sharing of authorized certificates. "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-03-12, 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. "DHCPv6 Failover Protocol", Tomek Mrugalski, Kim Kinnear, 2017-02-27, DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). "DHCPv6 Prefix Length Hint Issues", Tianxiang Li, Cong Liu, Yong Cui, 2017-01-25, DHCPv6 Prefix Delegation (RFC3633) allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. "Forcerenew Reconfiguration Extensions for DHCPv4", Luyuan Fang, Deepak Bansal, Fabio Chiussi, 2017-02-09, This document extends the definition of the DHCPFORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the DHCPFORCERENEW message more suitable to reconfigure configuration parameters other than IP addresses, and aligns the behavior of the reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCPv6. "Security of Messages Exchanged Between Servers and Relay Agents", Bernie Volz, Yogendra Pal, 2017-02-07, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. "Generalized UDP Source Port for DHCP Relay", Naiming Shen, Enke Chen, 2017-02-28, This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent UDP source port for DHCP packets. "DHCPv4 over DHCPv6 Source Address Option", Ian Farrer, Qi Sun, Yong Cui, Linhui Sun, 2017-03-09, DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It also describes a method for configuring the client with the IPv6 address of the border router so that the softwire can be established. It is designed to work in conjunction with the IPv4 address allocation process. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2017-03-13, 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-02-16, 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-07, 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-07, 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-03-09, 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. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Authenticated Received Chain (ARC) Protocol", Kurt Andersen, John Rae-Grant, Brandon Long, J. Adams, Steven Jones, 2016-12-02, Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM 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, 2016-12-27, 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-01-17, Additional Identifier Types are proposed 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-01-29, 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 in 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-03-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, 2016-07-25, The document [RFC4908] proposes to rely on multiple Care-of Addresses (CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO; [RFC3963]) to enable Multihoming technology for Small-Scale Fixed Networks. In the continuation of [RFC4908], this document specifies a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile IPv6 [RFC5213]. This extension allows a multihomed Mobile Access Gateway (MAG) to register more than one proxy care-of-address to the Local Mobility Anchor (LMA). "LMA Controlled MAG Session Parameters", Dhananjay Patki, Sri Gundavelli, Jong-Hyouk Lee, Qiao Fu, Lyle Bertz, 2017-03-11, This specification defines a new extension, LMA-Controlled-MAG- Session-Params to Proxy Mobile IPv6. This option can be used by the local mobility anchor in Proxy Mobile IPv6 signaling for notifying the mobile access gateway to conform to various parameters contained in this extension. "Home Network Prefix Renumbering in PMIPv6", Zhiwei Yan, Jong-Hyouk Lee, XiaoDong Lee, 2017-02-15, In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when an HNP renumbering has happened (e.g. due to change of service provider, change of site topology, etc.). In this document, a solution to support the HNP renumbering is proposed, as an update of the PMIPv6 specification. "DMM Deployment Models and Architectural Considerations", Sri Gundavelli, Seil Jeon, 2017-02-21, 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, 2016-12-15, 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 or network slice 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 prefix which is allocated from and is therefore 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) ------------------------------------- "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2016-12-24, This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2017-03-03, This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] "DNS catalog zones", Mukund Sivaraman, Stephen Morris, Ray Bellis, Witold Krecicki, 2017-01-06, 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. "Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY", Joe Abley, Olafur Gudmundsson, Marek Majkowski, 2017-02-08, The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. The DNS specification does not include specific guidance for the behaviour of DNS servers or clients in this situation. This document aims to provide such guidance. "A Common Operational Problem in DNS Servers - Failure To Respond.", Mark Andrews, 2017-03-03, The DNS is a query / response protocol. Failure to respond or to respond correctly to queries causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other zone operators to apply to help reduce / eliminate the problem. The document does not look at the DNS data itself, just the structure of the responses. "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", Duane Wessels, Warren Kumari, Paul Hoffman, 2017-02-16, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. "DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara, 2017-03-13, 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. "DNS Delegation Requirements", Patrik Wallstrom, Jakob Schlyter, 2016-10-26, This document outlines a set of requirements on a well-behaved DNS delegation of a domain name. A large number of tools have been developed to test DNS delegations, but each tool uses a different set of requirements for what is a correct setup for a delegated domain name. However, there are few requirements on how to set up DNS in order to just make the delegation work. In order to have a well- behaved delegation that is robust to failures and also makes DNS resolvers behave consistently, there are a large number of things to consider. Based on this document, it should be possible to set up a fully functional DNS delegation for a domain name, but also to create a set of test specifications for how to test a DNS delegation. "DNS Scoped Data Through '_Underscore' Attribute Leaves", Dave Crocker, 2017-03-05, Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records that are associated with the parent domain. This specification explores the nature of this DNS usage and defines the "underscore names" registry with IANA. "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", Paul Wouters, Ondrej Sury, 2016-10-11, The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC-6944. "A DNS Query including A Main Question with Accompanying Questions", Jiankang Yao, Paul Vixie, Ning Kong, XiaoDong Lee, 2016-10-30, 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 mechanism can reduce the number of DNS round-trips per application work-unit. "Aggressive use of DNSSEC-validated Cache", Kazunori Fujiwara, Akira Kato, Warren Kumari, 2017-01-12, The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a range, and positive answers from wildcards. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase resilience to certain DoS attacks in some circumstances. This document updates RFC4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records (and positive answers in the presence of wildcards). [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.This document is being collaborated on in Github at: https://github.com/wkumari/draft-ietf- dnsop-nsec-aggressiveuse. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests.] "DNS Session Signaling", Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Allison Mankin, Tom Pusateri, 2017-03-13, The EDNS(0) Extension Mechanism for DNS is explicitly defined to only have "per-message" semantics. This document defines a new Session Signaling Opcode used to communicate persistent "per-session" operations, expressed using type-length-value (TLV) syntax, and defines an initial set of TLVs used to manage session timeouts and termination. "DNS wire-format over HTTP", Linjian Song, Paul Vixie, Shane Kerr, Runxia Wan, 2016-09-15, This memo introduces a way to tunnel DNS data over HTTP. This may be useful in any situation where DNS is not working properly, such as when there is middlebox misbehavior. "Special-Use Domain Names Problem Statement", Ted Lemon, Ralph Droms, Warren Kumari, 2017-03-13, The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2016-10-31, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. "Updating Resolver Algorithm", Kazunori Fujiwara, 2016-10-31, Parent side NS RRSet and glue records are all information to access servers for child zone. However, they may be overwritten by child zone data (zone apex NS RRSet and other A/AAAA RRSets). The overwrite makes name resolution unstable and induces vulnerabilities. RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it is deemed that that all cached data (authoritative data, non- authoritative data, referrals and glue records) are merged into one. Resolvers may answer non-authoritative data, referrals and glue records that should not be returned. This document proposes updating resolver algorithm that separates the cache to "authoritative data cache" and "delegation cache". The former is used to answer stub resolvers, and the latter is used to iterate zones. "C-DNS: A DNS Packet Capture Format", John Dickinson, Jim Hague, Sara Dickinson, Terry Manderson, John Bond, 2017-02-21, 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. "DNS Response Policy Zones (RPZ)", Paul Vixie, Vernon Schryver, 2017-03-09, This document describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for recursive name servers to use such policy to return modified results to DNS clients. The modified DNS results can stop access to selected HTTP servers, redirect users to "walled gardens", block objectionable email, and otherwise defend against attack. These "DNS Firewalls" are widely used in fighting Internet crime and abuse. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "Discovery Proxy for Multicast DNS-Based Service Discovery", Stuart Cheshire, 2017-03-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. "On Interoperation of Labels Among Conventional DNS and Other Resolution Systems", Andrew Sullivan, 2017-01-03, Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. "DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2017-03-13, 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. 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-03-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-03-07, This document proposes a device pairing mechanism that establishes a relationship 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. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Stephane Fouant, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2016-11-17, 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 the DOTS exchanges. The purpose of the use cases is to identify the interacting DOTS component, 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-03-13, 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, 2016-10-31, 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. DNS PRIVate Exchange (dprive) ----------------------------- "Authentication and (D)TLS Profile for DNS-over-(D)TLS", Sara Dickinson, Daniel Gillmor, Tirumaleswar Reddy, 2017-01-18, 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). This document also specifies new authentication mechanisms - it describes several ways a DNS client can use an authentication domain name to authenticate a DNS server. Additionally, it defines (D)TLS profiles for DNS clients and servers implementing DNS-over-(D)TLS. "Padding Policy for EDNS(0)", Alexander Mayrhofer, 2016-12-05, RFC 7830 specifies the EDNS0 'Padding' option, but does not specify the amount of padding to be used in specific applications. This memo lists the possible options ("Padding Policies"), discusses the implications of each of these options, and provides implementation guidance. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane, 2016-10-29, 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-03-12, 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, 2016-11-27, This document describes a revised protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original [RFC7242] and updates to the Bundle Protocol contents, encodings, and convergence layer requirements in [I-D.ietf-dtn-bpbis]. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Next-Generation Pan-European eCall", Randall Gellens, Hannes Tschofenig, 2017-02-14, This document describes how to use IP-based emergency services mechanisms to support the next generation of the pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME media types and an Emergency Call Additional Data Block for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests. Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology can be re-used or extended to suit requirements across jurisdictions. "Next-Generation Vehicle-Initiated Emergency Calls", Randall Gellens, Brian Rosen, Hannes Tschofenig, 2017-01-19, This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME media type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and a SIP INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the metadata/control object to permit greater functionality. This document registers a new SIP INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. General Area (gen) ------------------ "Experiences from Cross-Area Work at the IETF", Jari Arkko, 2013-02-06, This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. "Intellectual Property Rights in IETF Technology", Scott Bradner, Jorge Contreras, 2017-03-08, The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFC 3979 and RFC 4879. Geographic JSON (geojson) ------------------------- "GeoJSON Text Sequences", Sean Gillies, 2017-02-16, This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type. This format is based on JavaScript Object Notation (JSON) Text Sequences and GeoJSON, and makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence. Global Routing Operations (grow) -------------------------------- "Default EBGP Route Propagation Behavior Without Policies", Jared Mauch, Job Snijders, Greg Hankins, 2017-02-21, This document defines the default behavior of a BGP speaker when there is no import or export policy associated with an External BGP session. "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions", Colin Petrie, Thomas King, 2017-01-14, This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to support the Advertisement of Multiple Paths in BGP extensions. "Usage of Large BGP Communities", Job Snijders, Martijn Schmidt, 2016-10-30, Examples and inspiration for operators on how to use Large BGP Communities. "Use of BGP Large Communities", Job Snijders, John Heasley, Martijn Schmidt, 2017-03-13, Examples and inspiration for operators to use BGP Large Communities. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu, 2017-02-15, 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-02-15, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, 2017-02-05, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. Home Networking (homenet) ------------------------- "Homenet profile of the Babel routing protocol", Juliusz Chroboczek, 2016-12-02, 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 and Babel. "Redacting .home from HNCP", Ted Lemon, 2017-03-13, This document updates the Home Networking Control Protocol, eliminating the recommendation for a default top-level name for local name resolution. "Special Use Top Level Domain '.homenet'", Pierre Pfister, Ted Lemon, 2017-03-13, This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.homenet.', and designates this top-level domain as a special-use domain name. The '.homenet' top-level domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Research into Human Rights Protocol Considerations", Niels Oever, Corinne Cath, 2017-02-25, 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 document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. This documents is a consensus document of the Human Rights Protocol Consideration Research Group of the Internet Research Task Force (IRTF). Discussion of this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/listinfo/hrpc Hypertext Transfer Protocol Authentication (httpauth) ----------------------------------------------------- "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2016-11-13, This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2016-11-13, This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Hypertext Transfer Protocol (httpbis) ------------------------------------- "Opportunistic Security for HTTP", Mark Nottingham, Martin Thomson, 2017-01-31, This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. 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/opp-sec . "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 2017-02-20, By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231. This document obsoletes RFC 5987. "HTTP Client Hints", Ilya Grigorik, 2016-12-02, An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences. "Encrypted Content-Encoding for HTTP", Martin Thomson, 2017-03-02, This memo introduces a content coding for HTTP that allows message payloads to be encrypted. 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/encryption . "The ORIGIN HTTP/2 Frame", Mark Nottingham, Erik Nygren, 2017-02-12, 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, 2016-10-31, 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 . "HTTP State Management Mechanism", Adam Barth, Mike West, 2016-10-10, 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 2965. "HTTP Header Common Structure", Poul-Henning Kamp, 2016-12-12, 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 . "HTTP Immutable Responses", Patrick McManus, 2017-03-13, The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This assures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified. "An HTTP Status Code for Indicating Hints", Kazuho Oku, 2017-02-08, This memo introduces an informational status code for HTTP that can be used for indicating hints to help a client start making 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-02-08, 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-03-07, To accommodate byte range requests for content that has data appended over time, this document defines semantics that allow a HTTP client and server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and ends at an indeterminate offset. Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Analysis of Existing work for I2NSF", Susan Hares, Robert Moskowitz, Dacheng Zhang, 2017-03-06, This document analyzes the current state of the art for security management devices and security devices technologies in industries and the existing IETF work/protocols that are relevant to the Interface to Network Security Function (I2NSF). The I2NSF focus is to define data models and interfaces in order to control and monitor the physical and virtual aspects of network security functions. "I2NSF Problem Statement and Use cases", Susan Hares, Diego Lopez, Myo Zarny, Christian Jacquenet, Rakesh Kumar, Jaehoon Jeong, 2017-03-08, This document describes the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, Henk Birkholz, 2017-03-07, 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, 2016-10-30, 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 in which the packet is associated. "Requirements for Client-Facing Interface to Security Controller", Rakesh Kumar, Anil Lohiya, Dave Qi, Nabil Bitar, Senad Palislamovic, Liang Xia, 2016-10-28, This document captures the requirements for the client-facing interface to the security controller. The interfaces are based on user constructs understood by a security admin instead of a vendor or a device specific mechanism requiring deep knowledge of individual products and features. This document identifies the requirements needed to enforce the user-construct oriented policies onto network security functions (NSFs) irrespective of how those functions are realized. The function may be physical or virtual in nature and may be implemented in networking or dedicated appliances. "Information Model of NSFs Capabilities", Liang Xia, John Strassner, Cataldo Basile, Diego Lopez, 2017-03-12, 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. Interface to the Routing System (i2rs) -------------------------------------- "Routing Information Base Info Model", Nitin Bahadur, Sriganesh Kini, Jan Medved, 2016-12-22, 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. "Summary of I2RS Use Case Requirements", Susan Hares, Mach Chen, 2016-11-15, The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh Kini, Nitin Bahadur, 2017-01-04, 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-03-01, This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. "A YANG Data Model for Layer 3 Topologies", Alexander Clemm, Jan Medved, Robert Varga, Xufeng Liu, Hariharan Ananthakrishnan, Nitin Bahadur, 2017-01-04, This document defines a YANG data model for layer 3 network topologies. "I2RS Ephemeral State Requirements", Jeffrey Haas, Susan Hares, 2016-11-16, The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. "I2RS Security Related Requirements", Susan Hares, Daniel Migault, Joel Halpern, 2016-09-29, This presents security-related requirements for the I2RS protocol which provides a new interface to the routing system described in the I2RS architecture document (RFC7921). The I2RS protocol is a re-use protocol implemented by re-using portions of existing IETF protocols and adding new features to these protocols. The I2RS protocol re- uses security features of a secure transport (E.g. TLS, SSH, DTLS) such as encryption, message integrity, mutual peer authentication, and replay protection. The new I2RS features to consider from a security perspective are: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier which identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport. This document provides the detailed requirements for these security features. "I2RS Environment Security Requirements", Daniel Migault, Joel Halpern, Susan Hares, 2017-03-12, 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). "Filter-Based Packet Forwarding ECA Policy", Susan Hares, Linda Dunbar, Russ White, 2017-03-13, This document describes the yang data model for packet forwarding policy that filters received packets and forwards (or drops) the packets. Filters for Layer 2, Layer 3, Layer 4, and packet-arrival time are linked together to support filtering for the routing layer. Prior to forwarding the packets out other interfaces, some of the fields in the packets may be modified. (If one considers the packet reception an event, this packet policy is a minimalistic Event-Match Condition-Action policy.) This policy controls forwarding of packets received by a routing device on one or more interfaces on which this policy is enabled. This data model may be used in either the configuration datastore, control plane datastores, or the I2RS ephemeral control plane datastore. "Filter-Based RIB Data Model", Susan Hares, Sriganesh Kini, Linda Dunbar, Ram Krishnan, Dean Bogdanovic, Russ White, 2017-03-13, This document defines a data model to support the Filter-based Routing Information Base (RIB) Yang data models. A routing system uses the Filter-based RIB to program FIB entries that process incoming packets by matching on multiple fields within the packet and then performing a specified action on it. The FB-RIB can also specify an action to forward the packet according to the FIB entries programmed using the RIBs of its routing instance. The Filter based RIB is a protocol independent data structure which can be deployed in a configuration datastore, an ephemeral control plane data stroe. Internet Architecture Board (iab) --------------------------------- "Digital Preservation Considerations for the RFC Series", Heather Flanagan, 2017-02-28, The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs, and the tools required to view or re-create RFCs as necessary. This document also highlights where gaps are in the current process, and where compromises are suggested to balance cost with ideal best practice. "Confidentiality in the Face of Pervasive Surveillance", Ted Hardie, 2016-10-27, The IAB has published [RFC7624] in response to several revelations of pervasive attack on Internet communications. This document surveys the most plausible mitigations to those threats currently available to the designers of Internet protocols. "Planning for Protocol Adoption and Subsequent Transitions", Dave Thaler, 2017-03-08, Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions, and thus some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and also summarizes what makes for a good transition plan. "Improving the Public Key Infrastructure (PKI) for the World Wide Web", Russ Housley, Karen O'Donoghue, 2016-10-31, The Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) is a vital component of trust in the Internet. In recent years, there have been a number of improvements made to this infrastructure, including improved certificate status checking, automation, and transparency of governance. However, additional improvements are necessary. This document identifies continuing areas of concern and provides recommendations to the Internet community for additional improvements, moving toward a more robust and secure Web PKI. "Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016", Jaime Jimenez, Hannes Tschofenig, Dave Thaler, 2016-11-14, This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIAG], [IOTSIWS], which took place in Santa Clara, CA, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and standards developing organizations to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop. "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report", Kathleen Moriarty, Mat Ford, 2017-01-05, This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. "Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016", Hannes Tschofenig, Stephen Farrell, 2017-02-03, This document provides a summary of the 'Workshop on Internet of Things (IoT) Software Update (IOTSU)' which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community. 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, 2016-12-22, 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-02-27, 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@parc.com, Ignacio Solis, Christopher Wood, 2017-03-13, 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@parc.com, Ignacio Solis, Christopher Wood, 2017-03-13, 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. "Using ICN in disaster scenarios", Jan Seedorf, Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2017-03-13, 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. Inter-Domain Routing (idr) -------------------------- "AS Path Based Outbound Route Filter for BGP-4", Susan Hares, Keyur Patel, 2016-12-19, This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 2016-12-02, Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. "Dissemination of Flow Specification Rules for IPv6", Danny McPherson, Robert Raszuk, Burjiz Pithawala, akarch@cisco.com, Susan Hares, 2017-03-13, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, Kevin Wang, 2017-01-05, This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients 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-03-04, The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, 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. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 2016-12-29, The current route target distribution specification as described in [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC 5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. "BGP Custom Decision Process", Alvaro Retana, Russ White, 2017-02-03, The BGP specification describes a Decision Process for selecting the best route. This process uses a series of steps, made up of path attributes and other values, to first determine the Degree of Preference of a route and later as tie breakers. While existing mechanisms may achieve some of the same results described in this document, they can only do so through extensive configuration such as matching communities to explicit policy and/or route preference configurations present on each BGP speaker within their administrative domain (autonomous system). Implementing some specific fine grained policies through such mechanisms is cumbersome, if even possible. This document defines a new Extended Community, called the Cost Community, which may be used as part of the Decision Process. The end result is a local Custom Decision Process. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 2016-12-10, The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart 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", Pradosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 2016-10-03, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Juan Alcaide, Clarence Filsfils, David Smith, Pradosh Mohapatra, 2017-03-13, This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. "Inter-domain SLA Exchange Attribute", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 2017-01-30, Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA 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 SLA 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", Stefano Previdi, Qin Wu, Hannes Gredler, Saikat Ray, jefftant@gmail.com, Clarence Filsfils, Les Ginsberg, 2016-10-31, 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-01-06, 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. "BGP Extensions for Service-Oriented MPLS Path Programming (MPP)", Zhenbin Li, Shunwan Zhuang, Sujian Lu, 2016-10-30, Service-oriented MPLS programming (SoMPP) is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to download programmed MPLS path and map the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2016-11-14, 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, Stephane Litkowski, Shunwan Zhuang, 2016-12-29, 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, 2016-11-28, 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 defined in [RFC7308] 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. "Segment Routing BGP Egress Peer Engineering BGP-LS Extensions", Stefano Previdi, Clarence Filsfils, Keyur Patel, Saikat Ray, Jie Dong, Mach Chen, 2017-03-13, 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. "BGP Community Container Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Bruno Decraene, Shane Amante, Paul Jakma, 2017-03-02, Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Thomas King, 2017-03-11, When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses a newly defined BGP SAFI to signal the state of the data link to the route server(s). "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Brian Dickson, Keyur Patel, Andrei Robachevsky, 2017-03-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, 2016-11-21, 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), 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, Keyur Patel, Arjun Sreekantiah, Saikat Ray, Hannes Gredler, 2016-12-12, 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 "segments". Each segment represents a topological or a service-based instruction. Per-flow state is maintained only at the ingress node of the SR domain. This document describes the BGP extension for announcing BGP Prefix Segment Identifier (BGP Prefix SID) information. "Applying BGP flowspec rules on a specific interface set", Stephane Litkowski, Adam Simpson, Keyur Patel, Jeffrey Haas, Lucy Yong, 2017-03-11, BGP flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP flowspec where flow specifications are used to maintain some access control lists at network boundary. BGP flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP flowspec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. "BGP Flow Specification Filter for MPLS Label", Lucy Yong, Susan Hares, liangqiandeng, Jianjie You, 2016-12-06, This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. "Carrying Label Information for BGP FlowSpec", liangqiandeng, Susan Hares, Jianjie You, Robert Raszuk, danma@cisco.com, 2016-12-06, This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. "BGP Flow Specification Packet-Rate Action", Wesley Eddy, Justin Dailey, Gilbert Clark, 2016-12-02, This document defines a new type of traffic filtering action for the BGP flow specification. The new packet-rate action allows specifying a rate-limit in number of packets per second. This is intended to be used in combatting some types of denial of service attacks where the packet rate is more important than the raw bitrate of the attack traffic. "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2017-03-02, Flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particularly if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new extended community known as redirect-to- indirection-id (32-bit) flowspec action to provide advanced redirection capabilities on flowspec clients. When activated, the flowspec extended community is used by a flowspec client to find the correct next-hop entry within a localised indirection-id mapping table. The functionality present in this draft allows a network controller to decouple flowspec functionality from the creation and maintainance of the network's service plane itself including the setup of tunnels and other service constructs that could be managed by other network devices. "BGP Link-State extensions for Segment Routing", Stefano Previdi, Peter Psenak, Clarence Filsfils, Hannes Gredler, Mach Chen, jefftant@gmail.com, 2017-02-09, 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. "BGP Administrative Shutdown Communication", Job Snijders, Jakob Heitz, John Scudder, 2017-03-03, This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. "Advertising Node Admin Tags in BGP Link-State Advertisements", Pushpasis Sarkar, Hannes Gredler, Stephane Litkowski, 2016-12-01, 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, Robert Raszuk, Danny McPherson, Christoph Loibl, Martin Bacher, 2017-02-23, 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. This draft 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 of inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial- of-service attacks; 2) application 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 of 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. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "Requirements for Marking SIP Messages to be Logged", Peter Dawes, Chidambaram Arunachalam, 2017-01-16, SIP networks use signaling monitoring tools to debug customer reported problems and for regression testing if network or client 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 clients, and therefore impractical to monitor SIP signaling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. "Marking SIP Messages to be Logged", Peter Dawes, 2017-02-13, SIP networks use signalling 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 signalling will take between user agents, and therefore impractical to monitor SIP signalling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular user agent signalling. However, such marking can be carried end-to-end including the SIP user agents, even if a session originates and terminates in different networks. Internet Area (int) ------------------- "IEEE 802.15.4 Information Element for IETF", Tero Kivinen, Pat Kinney, 2017-03-01, IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for IETF, and describes how the IE is formatted to provide subtypes. "Special-Purpose IP Address Registries", Ron Bonica, Michelle Cotton, Brian Haberman, Leo Vegoda, 2017-03-10, This memo updates the IANA IPv6 Special-Purpose Address Registries to address issues raised by the definition of a global prefix. For completeness, this memo contains all the assignments made to the IANA Special-Purpose Address Registries. This memo obsoletes RFC 6890. Internet Area Working Group (intarea) ------------------------------------- "IP Tunnels in the Internet Architecture", Joseph Touch, W. Townsley, 2017-03-13, 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. "IP over Intentionally Partially Partitioned Links", Erik Nordmark, 2016-10-26, IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. "Privacy considerations for IP broadcast and multicast protocol designers", Rolf Winter, Michael Faath, Fabian Weisshaar, 2017-02-13, 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-03-13, 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. IP Performance Metrics (ippm) ----------------------------- "Model Based Metrics for Bulk Transport Capacity", Matt Mathis, Al Morton, 2017-02-28, 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 peer-reviewed 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 on test streams that mimic TCP over the complete path and statistical criteria for evaluating the packet transfer statistics of those streams. 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. Model Based Metrics exhibit several important new properties not present in other Bulk Transport Capacity Metrics, including the ability to reason about concatenated or overlapping subpaths. The results are vantage independent which is critical for supporting independent validation of tests by comparing results from multiple measurement points. This document does not define the IP diagnostic tests, but provides a framework for designing suites of IP diagnostic tests that are tailored to confirming that infrastructure can meet the predetermined Target Transport Performance. "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip Eardley, Al Morton, Aamer Akhter, 2017-03-10, 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. "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", Nalini Elkins, Rob Hamilton, mackermann@bcbsm.com, 2017-03-13, To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. "Initial Performance Metric Registry Entries", Al Morton, Marcelo Bagnulo, Philip Eardley, Kevin D'Souza, 2017-03-10, This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * 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-02-22, 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 performance monitoring", Giuseppe Fioccola, Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Mach Chen, Lianshu Zheng, Gregory Mirsky, Tal Mizrahi, 2017-03-01, This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)", Gregory Mirsky, Israel Meilik, 2017-03-12, This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. "IPv6 Updates for IPPM's Active Metric Framework", Al Morton, Joachim Fabini, Nalini Elkins, mackermann@bcbsm.com, Vinayak Hegde, 2017-03-06, 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 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, or IPv6 header compression. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Postquantum Preshared Keys for IKEv2", Scott Fluhrer, David McGrew, Panos Kampanakis, 2016-10-28, This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys "Algorithm Implementation Requirements and Usage Guidance for IKEv2", Yoav Nir, Tero Kivinen, Paul Wouters, Daniel Migault, 2017-02-16, The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). "TCP Encapsulation of IKE and IPsec Packets", Tommy Pauly, Samy Touati, Ravi Mantha, 2017-03-12, This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", Daniel Migault, John Mattsson, Paul Wouters, Yoav Nir, Tero Kivinen, 2017-02-27, This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. "Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)", Yoav Nir, 2017-03-12, 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-03-13, 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". IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------- "Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside the Context of a Basic Service Set (IPv6-over-80211ocb)", Alexandre Petrescu, Nabil Benamar, Jerome Haerri, Christian Huitema, Jong-Hyouk Lee, Thierry Ernst, Tony Li, 2017-03-12, In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, 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. In addition, the document attempts to list what is different in 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n layers, layers over which IPv6 protocols operates without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. An example of an IPv6 packet captured while transmitted over an IEEE 802.11 OCB link (802.11p) is given. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Routing with Reverse Metric", Naiming Shen, Shane Amante, Mikael Abrahamsson, 2017-03-07, 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, 2016-10-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-03-07, 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. "Advertising Tunnelling Capability in IS-IS", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2016-10-14, 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 protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Zhaohui Zhang, Ladislav Lhotka, 2017-02-01, This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. "Signaling Entropy Label Capability Using IS-IS", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2016-10-14, Multi Protocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it can process ELs on that tunnel. This draft defines a mechanism to signal that capability using IS-IS. This mechanism is useful when the label advertisement is also done via IS-IS. "ISIS Auto-Configuration", Bing Liu, Bruno Decraene, Ian Farrer, Mikael Abrahamsson, Les Ginsberg, 2016-11-21, This document specifies IS-IS auto-configuration mechanisms. The key components are IS-IS System ID self-generation, duplication detection and duplication resolution. These mechanisms provide limited IS-IS functions, and so are suitable for networks where plug-and-play configuration is expected. "Advertising L2 Bundle Member Link Attributes in IS-IS", Les Ginsberg, Ahmed Bashandy, Clarence Filsfils, Stefano Previdi, Mohan Nanduri, Ebben Aries, 2017-02-20, 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. "IS-IS Multi-Instance", Les Ginsberg, Stefano Previdi, Wim Henderickx, 2016-11-13, This draft describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System To Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type Length Value (TLV) identifying the instance and the topology(ies) to which the PDU belongs. This draft updates RFC 6822 if approved. "Advertising Tunnelling Capability in IS-IS", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2016-10-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, I. Chen, Jeff Tantsura, 2016-11-03, 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-03-02, This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by an ISIS 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. Javascript Object Notation Update (jsonbis) ------------------------------------------- "The JavaScript Object Notation (JSON) Data Interchange Format", Tim Bray, 2017-02-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) --------------------------------------------------------- "Generic Security Service API Version 2: Java Bindings Update", Mayank Upadhyay, Seema Malkani, Wang Weijun, 2016-12-05, 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). "Authentication Indicator in Kerberos Tickets", Anupam Jain, Nathan Kinder, Nathaniel McCallum, 2017-02-09, This document updates RFC 4120 in order to specify an extension in the Kerberos protocol. It defines a new authorization data type AD- AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. "Kerberos Service Discovery using DNS", Nathaniel McCallum, Matt Rogers, 2017-02-09, This document proposes defines a new mechanism for discovering Kerberos services using DNS. This new mechanism extends the mechanism already defined in Kerberos V5 [RFC4120] and has four goals. First, reduce the number of DNS queries required to discover a Kerberos KDC. Second, provide DNS administrators more control over client behavior. Third, provide support for discovery of the MS- KKDCP transport. Fourth, define a discovery procedure for Kerberos password services. L2VPN Service Model (l2sm) -------------------------- "A YANG Data Model for L2VPN Service Delivery", Bin Wen, Giuseppe Fioccola, Chongfeng Xie, Luay Jalil, 2017-02-26, 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 use 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. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer Schatzmayr, Wim Henderickx, 2016-10-14, This document describes an Ethernet over IPv6 tunnel encapsulation with mandatory 64-bit cookie for connecting L2 Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on L2TPv3 over IP and does not use the L2TPv3 control plane. "A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing Liu, Giles Heron, 2016-10-28, This document defines a YANG data model for the configuration and management of Keyed IPv6 tunnels. The data model includes both configuration and state data. Due to the stateless nature of keyed IPv6 tunnels, a model for NETCONF notifications is not necessary. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", Jim Schaad, Blake Ramsdell, Sean Turner, 2017-03-13, 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-03-12, This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate 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-03-13, 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 3850. Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- "Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Qin Wu, Zitao Wang, 2017-03-06, 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) "Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-02-23, 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). "Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2017-02-23, This document presents a retrieval method YANG Data model for connectionless OAM protocols. It provides a technology-independent RPC commands 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 interactive OAM workflows ( i.e., performing OAM functions at same levels through a unified interface). Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2016-11-16, 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. "LISP Delegated Database Tree", Vince Fuller, Darrel Lewis, Vina Ermagan, Amit Jain, Anton Smirnov, 2017-01-18, This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. "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 Configuration YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Albert Cabellos-Aparicio, Fabio Maino, 2017-01-07, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2016-10-17, 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 de-capsulators at the receiver LISP multicast sites. "The Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, David Meyer, Darrel Lewis, Albert Cabellos-Aparicio, 2016-12-06, This document describes the Locator/ID Separation Protocol (LISP) data-plane encapsulation protocol. 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 [REF_TO_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, 2016-12-06, 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 experimentation 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. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- "Information Model for Large-Scale Measurement Platforms (LMAP)", Trevor Burbridge, Philip Eardley, Marcelo Bagnulo, Juergen Schoenwaelder, 2017-02-22, This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. "A YANG Data Model for LMAP Measurement Agents", Juergen Schoenwaelder, Vaibhav Bajpai, 2017-02-22, This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. IPv6 over Low Power Wide-Area Networks (lpwan) ---------------------------------------------- "LPWAN Static Context Header Compression (SCHC) for CoAP", Ana Minaburo, Laurent Toutain, 2017-03-10, This draft discusses the way SCHC header compression can be applied to CoAP headers in an LPWAN flow regarding the generated traffic. CoAP protocol differs from IPv6 and UDP protocols because the CoAP Header has a flexible header due to variable options. Another important difference is the asymmetric format in the header information used in the request and the response packets. This draft shows that the Client and the Server do not uses the same fields and how the SCHC header compression can be used. "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP", Ana Minaburo, Laurent Toutain, Carles Gomez, 2017-03-10, This document describes a header compression scheme and fragmentation functionality for IPv6/UDP protocols. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks and could be extended to other protocol stacks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. Static context means that information stored in the context which, describes field values, does not change during the packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document describes the generic compression/decompression process and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in a separate document. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 pdu size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent. "LPWAN Overview", Stephen Farrell, 2017-02-27, 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. "CoAP Implementation Guidance", Matthias Kovatsch, Olaf Bergmann, Carsten Bormann, 2017-03-13, The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks such as sensor nodes in a low-power lossy network (LLN). Yet to implement this Internet protocol on Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of ROM) also lightweight implementation techniques are necessary. This document provides lessons learned from implementing CoAP for tiny, battery-operated networked embedded systems. In particular, it provides guidance on correct implementation of the CoAP specification RFC 7252, memory optimizations, and customized protocol parameters. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Back, 2017-02-10, This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some preliminary experiences in implementing cryptography on small devices using those libraries, and discusses trade-offs involving different types of approaches. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Shawn Jury, Darryl Satterwhite, Rick Taylor, Bo Berry, 2017-03-05, When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. DLEP describes a new protocol for a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics. "Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Jiazi Yi, Benoit Parrein, 2016-07-25, This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. "Security Threats to the Optimized Link State Routing Protocol version 2 (OLSRv2)", Thomas Clausen, Ulrich Herberg, Jiazi Yi, 2017-01-11, This document analyzes common security threats that might apply to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. "Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ Message Format", Thomas Clausen, Christopher Dearlove, Ulrich Herberg, Henning Rogge, 2016-05-04, RFC 5444 specifies a generalized MANET packet/message format and describes an intended use to multiplex MANET routing protocol messages that is mandated for use 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 of RFC 5444 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 RFC 5444 parsers. "Credit Windowing extension for DLEP", Stan Ratliff, 2016-11-13, This draft describes an extension to the DLEP protocol to provide a credit-windowing scheme for destination-specific flow control. "DLEP Control Plane Based Pause Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2017-02-09, This document defines an extension to the DLEP protocol that enables a simple control plane based flow control mechanism. "DLEP Multi-Hop Forwarding Extension", Bow-Nan Cheng, Lou Berger, 2017-02-09, This document defines an extension to the DLEP protocol that enables a the reporting and control of Multi-Hop Forwarding by DLEP capable modems. "DLEP Lantency Range Extension", Bow-Nan Cheng, Lou Berger, 2017-02-09, This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. "DLEP DiffServ Aware Credit Windowing Extension", Bow-Nan Cheng, David Wiggins, Lou Berger, 2017-03-13, This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-windowing scheme for destination-specific flow control. MBONE Deployment (mboned) ------------------------- "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Kerry Meyer, Weesan Lee, 2017-03-13, 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-02-02, 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) -------------------------------------------- "IODEF Usage Guidance", Panos Kampanakis, Mio Suzuki, 2017-03-12, The Incident Object Description Exchange Format v2 [RFC7970] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. 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 can leverage IODEF for incident sharing. This document provides guidelines for IODEF practitioners. It also addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. "MILE Implementation Report", Christopher Inacio, Daisuke Miyamoto, 2016-11-13, This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups. "Resource-Oriented Lightweight Information Exchange", John Field, Stephen Banghart, David Waltermire, 2017-03-13, 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 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. "XMPP Protocol Extensions for Use with IODEF", Nancy Cam-Winget, Syam Appala, Scott Pope, 2016-10-15, This document describes the extensions made to Extensible Messaging and Presence Protocol (XMPP) [RFC6120]that enables the use of XMPP as a transport protocol for collecting and distributing any security telemetry information between and among network platforms, endpoints, and most any network connected device. Specifically, this document will focus on how these extensions can be used to transport the Incident Object Description Exchange Format (IODEF) information. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 2017-02-04, 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-03-13, 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, 2016-10-27, 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. "Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)", Marc Petit-Huguenin, Ari Keranen, Suhas Nandakumar, 2017-03-13, This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). "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-03-03, 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). "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2017-03-13, 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-01-15, 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, 2016-10-19, 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). "Using the SDP Offer/Answer Mechanism for DTLS", Christer Holmberg, Roman Shpount, 2017-03-12, This document defines the SDP offer/answer procedures for negotiating and establishing a 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, 'dtls-id'. "RTP Payload Format Restrictions", Peter Thatcher, Mo Zanaty, Suhas Nandakumar, Bo Burman, Adam Roach, Byron Campen, 2017-03-13, 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-02-17, 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. "Connection-Oriented Media Transport over TLS in SDP", Jonathan Lennox, Christer Holmberg, 2017-02-02, This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------------------------------------------ "Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom McGarry, 2017-03-13, 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-03-08, 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). "MPLS Transport Profile Linear Protection MIB", Kingston Smiler, Venkatesan Mahalingam, Daniel King, Sam Aldrin, Jeong-dong Ryoo, 2017-02-17, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing Multiprotocol Label Switching-Transport Profile (MPLS-TP) Linear Protection. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, George Swallow, 2016-10-19, This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS. "LDP Extensions to Support Maximally Redundant Trees", Alia Atlas, Kishore Tiruveedhula, Chris Bowers, Jeff Tantsura, IJsbrand Wijnands, 2017-02-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. "Application-aware Targeted LDP", Santosh Esale, Raveendra Torvi, Luay Jalil, Uma Chunduri, Kamran Raza, 2017-02-07, Recent targeted LDP (tLDP) applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- label bindings over the session. This document updates RFC 7473. "RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon, Tarek Saad, Rakesh Gandhi, Abhishek Deshmukh, Markus Jork, Vishnu Beeram, 2017-03-09, 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. "Opportunistic Security in MPLS Networks", Adrian Farrel, Stephen Farrell, 2016-09-20, This document describes a way to apply opportunistic security between adjacent nodes on an MPLS Label Switched Path (LSP) or between end points of an LSP. It explains how keys may be agreed to enable encryption, and how key identifiers are exchanged in encrypted MPLS packets. Finally, this document describes the applicability of this approach to opportunistic security in MPLS networks with an indication of the level of improved security as well as the continued vulnerabilities. This document does not describe security for MPLS control plane protocols. "Residence Time Measurement in MPLS network", Gregory Mirsky, Stefano Ruffini, Eric Gray, John Drake, Stewart Bryant, Sasha Vainshtein, 2017-03-07, This document specifies a new Generic Associated Channel for Residence Time Measurement and describes how it can be used by time synchronization protocols within a MPLS domain. Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a Precision Time Protocol event message. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Gregory Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2017-02-06, 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 specific path for the reverse direction of the BFD session. "Shared-Ring protection (MSRP) mechanism for ring topology", Weiqiang Cheng, Lei Wang, Han Li, Huub van Helvoort, Jie Dong, 2016-12-13, This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2017-03-11, This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. "MPLS Flow Identification Considerations", Stewart Bryant, Carlos Pignataro, Mach Chen, Zhenbin Li, Gregory Mirsky, 2017-02-24, 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. "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", Kireeti Kompella, George Swallow, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Mach Chen, 2016-10-28, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. "Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula, Uwe Joorde, Arvind Venkateswaran, 2016-09-26, 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. "Use Cases and Requirements for MPLS-TP multi-failure protection", Zhenlong Cui, Rolf Winter, Himanshu Shah, Sam Aldrin, Masahiro Daikoku, 2017-02-21, For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. "LDP Specification", Xia Chen, Loa Andersson, Nicolai Leymann, Ina Minei, Kamran Raza, 2016-10-23, 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. "Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode", Jeong-dong Ryoo, Tae-sik Cheung, Huub van Helvoort, Italo Busi, Guangjuan Weng, 2017-02-21, This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic, in which the state machine resides, when operating in APS mode, and clarify some operation related to state transition table lookup. "Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane", Nagendra Kumar, George Swallow, Carlos Pignataro, Nobo Akiya, Sriganesh Kini, Hannes Gredler, Mach Chen, 2016-12-01, Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to 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 in LSP with Segment Routing architecture. This document illustrates the problem and describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over 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-03-12, 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-03-13, 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-02-12, 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 larger 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. "Using BGP to Bind MPLS Labels to Address Prefixes", Eric Rosen, 2017-03-13, This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. "YANG Data Model for MPLS mLDP", Kamran Raza, Sowmya Krishnaswamy, Xufeng Liu, Santosh Esale, Xia Chen, Jeff Tantsura, 2017-03-13, 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-03-13, 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. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch, 2016-10-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", Ray Pelletier, Laura Nugent, Dave Crocker, Lou Berger, Ole Jacobsen, Jim Martin, Fred Baker, Eliot Lear, 2017-03-12, The IAOC 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-03-10, 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, 2017-03-13, This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its 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-03-01, This document defines a subscription and push mechanism for YANG datastores. This mechanism allows subscriber applications to request updates from a YANG datastore, which are then pushed by the publisher to a receiver per a subscription policy, without requiring additional subscriber requests. "TLS Client and Server Models", Kent Watsen, Gary Wu, 2017-03-13, 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-03-13, 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-03-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-03-13, 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-03-13" --> the publication date of this draft The following two Appendix sections are to be removed prior to publication: o Appendix A. Change Log o Appendix B. Open Issues "NETCONF Support for Event Notifications", Alberto Prieto, Alexander Clemm, Eric Voit, Einar Nilsen-Nygaard, Ambika Tripathy, Sharon Chisholm, Hector Trevino, 2016-10-31, This document defines the support of [event-notifications] by the Network Configuration protocol (NETCONF). [event-notifications] describes capabilities and operations for providing asynchronous message notification delivery. This document discusses how to provide them on top of NETCONF. The capabilities and operations defined between this document and [event-notifications] are intended to obsolete RFC 5277. "Restconf and HTTP Transport for Event Notifications", Eric Voit, Alberto Prieto, Ambika Tripathy, Einar Nilsen-Nygaard, Alexander Clemm, Andy Bierman, 2017-03-13, This document defines Restconf, HTTP2, and HTTP1.1 bindings for the transport of Subscription requests and corresponding push updates. Being subscribed may be either Event Notifications or objects or subtress of YANG Datastores. "Keystore Model", Kent Watsen, 2017-03-13, This document defines a YANG data module for a system-level keystore mechanism, that might be used to hold onto private keys and certificates that are trusted by the system advertising support for this module. "Network Configuration Protocol (NETCONF) Access Control Model", Andy Bierman, Martin Bjorklund, 2017-03-13, 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. "Subscribing to Event Notifications", Eric Voit, Alexander Clemm, Alberto Prieto, Einar Nilsen-Nygaard, Ambika Tripathy, 2017-02-23, This document defines capabilities and operations for subscribing to content and providing asynchronous notification message delivery on that content. Notification delivery can occur over a variety of protocols used commonly in conjunction with YANG, such as NETCONF and RESTCONF. The capabilities and operations defined in this document when using in conjunction with draft-ietf-netconf-netconf-event- notifications are intended to obsolete RFC 5277. NETCONF Data Modeling Language (netmod) --------------------------------------- "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2017-03-05, 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. "A YANG Data Model for Syslog Configuration", Clyde Wildes, Kiran Koushik, 2017-03-13, This document describes a data model for the configuration of syslog. "Network Access Control List (ACL) YANG Data Model", Dean Bogdanovic, Kiran Koushik, Lisa Huang, Dana Blair, 2017-03-13, 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. o Revision date in model (Oct 12, 2016) 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 Module Classification", Dean Bogdanovic, Benoit Claise, Carl Moberg, 2017-03-13, The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. "YANG Schema Mount", Martin Bjorklund, Ladislav Lhotka, 2017-03-06, 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-03-13, 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-03-13, 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-03-13, 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-03-13, 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. Internet Video Codec (netvc) ---------------------------- "