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 2015-12-28 04:08:55 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, 2015-09-15, DECT Ultra Low Energy 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, 2015-10-19, Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer, which is used extensively 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", Joo-Sang Youn, Yong-Geun Hong, 2015-10-17, 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. "Privacy Considerations for IPv6 over Networks of Resource-Constrained Nodes", Dave Thaler, 2015-10-18, This document discusses how a number of privacy threats apply to technologies designed for IPv6 over networks of resource-constrained nodes, and provides advice to protocol designers on how to address such threats in IPv6-over-foo adaptation layer specifcations. "An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX)", Yoshihiro Ohba, 2015-11-24, HIP DEX (Host Identity Protocol Diet EXchange) is a light-weight key exchange protocol designed for constrained devices. MLE (Mesh Link Establishment) is defined for establishing and configuring secure links in IEEE 802.15.4 mesh networks. This document defines an extension of MLE protocol to encapsulate HIP DEX key exchange protocol messages. "Mesh Link Establishment", Richard Kelsey, 2015-12-01, This document defines the mesh link establishment (MLE) protocol for establishing and configuring secure radio links in IEEE 802.15.4 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop mesh networks by adding three capabilities: 1) dynamically configuring and securing radio connections between neighboring devices, 2) enabling network-wide changes to shared radio parameters, and 3) allowing the determination of radio link quality prior to configuration. MLE operates below the routing layer, insulating it from the details of configuring, securing, and maintaining individual radio links within a larger mesh network. "6LoWPAN Routing Header And Paging Dispatches", Pascal Thubert, Carsten Bormann, Laurent Toutain, Robert Cragie, 2015-12-04, This specification introduces a new context switch mechanism for 6LoWPAN compression, expressed in terms of Pages and signaled by a new Paging Dispatch. A new 6LoWPAN dispatch type is proposed in a new Page 1 for use in 6LoWPAN Route-Over topologies, that initially covers the needs of RPL (RFC6550) data packets compression. This specification defines a method to compress RPL Option (RFC6553) information and Routing Header type 3 (RFC6554), an efficient IP-in- IP technique and is extensible for more applications. IPv6 Maintenance (6man) ----------------------- "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 2015-10-09, IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the "Identification" field is that the corresponding value must be different than that employed for any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for selecting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. "Privacy Considerations for IPv6 Address Generation Mechanisms", Alissa Cooper, Fernando Gont, Dave Thaler, 2015-09-23, This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. "Recommendation on Stable IPv6 Interface Identifiers", Fernando Gont, Alissa Cooper, Dave Thaler, Shucheng LIU, 2015-10-13, This document changes the recommended default Interface Identifier generation scheme for SLAAC to that specified in RFC7217, and recommends against embedding link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and RFC5121, which require IPv6 Interface Identifiers to be derived from the underlying link-layer address. Additionally, this document provides advice about the generation of Interface Identifiers with Dynamic Host Configuration Protocol version 6 (DHCPv6) (thus updating RFC3315) and manual configuration. "Deprecation of the Generation of IPv6 Atomic Fragments", Fernando Gont, Shucheng LIU, Tore Anderson, 2015-11-26, RFC2460 requires that when a host receives an ICMPv6 "Packet Too Big" message reporting an MTU smaller than 1280 bytes, the host includes a Fragment Header in all subsequent packets sent to that destination, without reducing the assumed Path-MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can be forged, coupled with the widespread filtering of IPv6 fragments, results in an attack vector that can be leveraged for Denial of Service purposes. This document briefly discusses the aforementioned attack vector, and why the aforementioned functionality is undesirable. "IPv6 Router Advertisement Options for DNS Configuration", Jaehoon Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli, 2015-10-10, This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document obsoletes RFC 6106 and allows a higher default value of the lifetime of the RA DNS options to avoid the frequent expiry of the options on links with a relatively high rate of packet loss. "Republishing the IPV6-specific MIB modules as obsolete", Bill Fenner, 2015-08-25, 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. "IP Version 6 Addressing Architecture", Bob Hinden, Stephen Deering, 2015-10-19, 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". "Routing packets from hosts in a multi-prefix network", Fred Baker, Brian Carpenter, 2015-12-16, This document describes expected IPv6 host behavior in a network that has more than one prefix, each allocated by an upstream network that implements BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. This host behavior may interact with source address selection in a given implementation, but logically follows it. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861. "Internet Protocol, Version 6 (IPv6) Specification", Stephen Deering, Bob Hinden, 2015-12-15, This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. It obsoletes RFC2460 "IPv6 Hop-by-Hop Header Handling", Fred Baker, 2015-11-03, This note updates the IPv6 Specification (RFC 2460), specifically commenting on the Hop-by-Hop Options Header (section 4.3) and option format and handling (section 4.2). It also updates RFC 7045, which noted that RFC 2460 is widely violated in this respect, but merely legitimized this situation with a SHOULD. The present document tries to address the issue more fundamentally. "Support for adjustable maximum router lifetimes per-link", Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko, 2015-12-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, Brian Field, Ida Leung, J. Linkova, exa, Tomoya Kosugi, Eric Vyncke, David Lebrun, 2015-12-14, Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending a 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", Bob Hinden, Stephen Deering, 2015-12-16, This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". IPv6 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, 2015-11-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, 2015-11-02, 6TiSCH proposes an architecture for an IPv6 multi-link subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4e TSCH wireless networks attached and synchronized by backbone routers. This document extends existing terminology documents available for Low-power and Lossy Networks to provide additional terminology elements. "Minimal 6TiSCH Configuration", Xavier Vilajosana, Kris Pister, 2015-11-27, This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fall- back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development. "6TiSCH Operation Sublayer (6top) Interface", Qin Wang, Xavier Vilajosana, 2015-07-06, This document defines a generic data model for the 6TiSCH Operation Sublayer (6top), using the YANG data modeling language. This data model can be used for network management solutions defined by the 6TiSCH working group. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Josh Howlett, Sam Hartman, Alejandro Perez-Mendez, 2015-12-14, This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, users or machines (Clients). These Clients may be named using a NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any AAA scenario, such as the network access control. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, 2012-09-25, Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear, Jim Schaad, 2014-07-21, Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. "Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations", Rhys Smith, Mark Donnelly, 2015-10-19, The real world use of ABFAB-based technologies requires that any identity that is to be used for authentication has to be configured on the ABFAB-enabled client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, managing their identity information and identity-to-service mappings. All designers of software to fulfil this role will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency between implementations. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------------------------- "Use Cases for Authentication and Authorization in Constrained Environments", Ludwig Seitz, Stefanie Gerdes, Goran Selander, Mehdi Mani, Sandeep Kumar, 2015-10-26, Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Goran Selander, Carsten Bormann, 2015-10-19, 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. "Authorization for the Internet of Things using OAuth 2.0", Ludwig Seitz, Goran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2015-12-21, This memo defines how to use OAuth 2.0 as an authorization framework with Internet of Things (IoT) deployments, thus bringing a well-known and widely used security solution to IoT devices. Where possible vanilla OAuth 2.0 is used, but where the limitations of IoT devices require it, profiles and extensions are provided. Automated Certificate Management Environment (acme) --------------------------------------------------- "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, James Kasten, 2015-10-04, Certificates in the Web's X.509 PKI (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 certificate 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. DANGER: Do not implement this specification. It has a known signature reuse vulnerability. For details, see the following discussion: https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf- 4Yc Application-Layer Traffic Optimization (alto) --------------------------------------------- "Multi-Cost ALTO", Sabine Randriamasy, Wendy Roome, Nico Schwan, 2015-10-19, The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. For example, when downloading a file that is mirrored on several sites, a user application may use these ALTO cost metrics to determine the most efficient mirror site. 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. When selecting a mirror site, a client may consider more than one metric, perhaps trading bandwidth for latency. While the base ALTO Protocol allows a 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, 2015-09-29, 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. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian Carpenter, Bing Liu, 2015-10-08, This document establishes requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually 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, Steinthor Bjarnason, Balaji BL, Toerless Eckert, 2015-10-06, 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 Key Infrastructures", Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, 2015-10-19, This document specifies automated bootstrapping of an key infrastructure using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based service on the Internet. Before being authenticated, a new device has only link-local connectivity, and does not require a routable address. When a vendor provides an Internet based service, devices can be forced to join only specific domains but in limited/disconnected networks or legacy environments we describe a variety of options that allow bootstrapping to proceed. ART Area General Applications Working Group (appsawg) ----------------------------------------------------- "The text/markdown Media Type", Sean Leonard, 2015-10-17, This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. "Message Disposition Notification", Tony Hansen, Alexey Melnikov, 2015-12-02, This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. "Problem Details for HTTP APIs", mnot, Erik Wilde, 2015-12-05, This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to define new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. This section is to be removed before publication. Note to RFC Editor Please replace all occurrences of "XXXX" with the final RFC number chosen for this draft. This section is to be removed before publication. "Windows Image Media Types", Sean Leonard, 2015-09-04, This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and may contain both vector and raster graphics. "The file URI Scheme", Matthew Kerwin, 2015-11-30, This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It attempts to define a common core which is intended to interoperate across the broad spectrum of existing implementations, while at the same time documenting other current practices. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations", Sean Leonard, 2015-09-04, This document elaborates upon the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied. Active Queue Management and Packet Scheduling (aqm) --------------------------------------------------- "AQM Characterization Guidelines", N. Kuhn, Preethi Natarajan, Naeem Khademi, David Ros, 2015-11-27, Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet scheduling scheme such as fair queuing. The IETF Active Queue Management and Packet Scheduling working group was formed to standardize AQM schemes that are robust, easily implementable, and successfully deployable in today's networks. This document describes various criteria for performing precautionary characterizations of AQM proposals. This document also helps in ascertaining whether any given AQM proposal should be taken up for standardization by the AQM WG. "On Queuing, Marking, and Dropping", Fred Baker, Rong Pan, 2015-11-01, This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior. "The Benefits of using Explicit Congestion Notification (ECN)", Gorry Fairhurst, Michael Welzl, 2015-11-23, The goal of this document is to describe the potential benefits when applications use a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN, nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers or other network devices. "Controlled Delay Active Queue Management", Kathleen Nichols, Van Jacobson, Andrew McGregor, Jana Iyengar, 2015-12-01, This document describes a general framework called CoDel (Controlled Delay) [CODEL2012] 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. CoDel comprises some major technical innovations and has been made available as open source so that the framework can be applied by the community to a range of problems. It has been implemented in Linux (and available in the Linux distribution) and deployed in some networks at the consumer edge. In addition, the framework has been successfully applied in other ways. Note: Code Components extracted from this document must include the license as included with the code in Section 5. "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Rong Pan, Preethi Natarajan, Fred Baker, 2015-11-17, Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. "FlowQueue-Codel", Toke Hoeiland-Joergensen, Paul McKenney, dave.taht@gmail.com, Jim Gettys, Eric Dumazet, 2015-11-20, This memo presents the FQ-CoDel hybrid packet scheduler/AQM 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. "A PIE-Based AQM for DOCSIS Cable Modems", Greg White, Rong Pan, 2015-09-29, Cable modems based on the DOCSIS(R) specification provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on Active Queue Management that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems. Applications and Real-Time Area (art) ------------------------------------- "A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)", Marc Blanchet, Audric Schiltknecht, Peter Shames, 2015-10-15, This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS). "Improving the Organizational Flexibility of the SIP Change Process.", Ben Campbell, Alissa Cooper, Barry Leiba, 2015-06-19, RFC 5727 defines several processes for the Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. "URN Namespace for MEF Documents", Mahesh Jethanandani, 2015-12-16, This document describes the Namespace Identifier (NID) 'mef' for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (http://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry. 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. "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Colin Perkins, Varun Singh, 2015-10-16, The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP circuit-breakers. Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. "Sending Multiple RTP Streams in a Single RTP Session", Jonathan Lennox, Magnus Westerlund, Qin Wu, Colin Perkins, 2015-12-11, This memo expands and clarifies the behaviour of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regards to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTCP behaviour. It also updates RFC 4585 to update and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages. "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Jonathan Lennox, Magnus Westerlund, Qin Wu, Colin Perkins, 2015-12-15, 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. "Multipath RTP (MPRTP)", Varun, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 2015-07-06, The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints. "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2015-10-19, This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) packets are multiplexed on a single receiving socket. It overrides the guidance from SRTP Extension for DTLS [RFC5764], which suffered from three issues described and fixed in this document. "The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descritpions", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon, 2015-11-25, This document defines SRTP crypto suites based on the ARIA block cipher algorithm for use with the Session Descritpion Protocol (SDP) security descriptions. "A General Mechanism for RTP Header Extensions", Roni Even, David Singer, HariKishan Desineni, 2015-12-23, 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. Audio/Video Transport Extensions (avtext) ----------------------------------------- "RTP Stream Pause and Resume", Bo Burman, Azam Akram, Roni Even, Magnus Westerlund, 2015-09-11, With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli, 2015-11-26, 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. "RTP Header Extension for RTCP Source Description Items", Magnus Westerlund, Bo Burman, Roni Even, Mo Zanaty, 2015-07-06, Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. "The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2015-10-19, This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several scalable media formats. "Frame Marking RTP Header Extension", Espen Berger, Suhas Nandakumar, Mo Zanaty, 2015-10-19, 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 encryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. BGP Enabled Services (bess) --------------------------- "BGP-signaled end-system IP/VPNs.", Pedro Marques, Luyuan Fang, Nischal Sheth, Maria Napierala, Nabil Bitar, 2015-10-08, 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. These end-systems may be used to provide network services or may directly host end-to-end applications. "Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network", Hao Weiguo, Lucy Yong, Susan Hares, Osama Zia, Muhammad Durrani, 2015-09-10, This draft describes inter-as option-C solution between NVO3 network and MPLS/IP VPN network. Transport layer stitching solution should be provided. Also to ensure VPNv4 route exchange correctly between local NVE and remote PE, VNID space should be partitioned, only the VNIDs of lower 1 Million can be used for interconnection with outer MPLS VPN network using option-C solution, the rest 15 Million VNIDs can only be used for intra DC. "L2L3 VPN Multicast MIB", Jeffrey Zhang, 2015-08-11, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects common to both VPLS and VPN Multicast. "MPLS/BGP Layer 3 VPN Multicast Management Information Base", Jeffrey Zhang, Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain, 2015-08-11, This memo defines an 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 multicast in MPLS/BGP-based Layer-3 VPN (MVPN) on an MVPN router. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Florin Balus, Keyur Patel, Ali Sajassi, 2015-07-04, 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, Aldrin Isaac, Jim Uttaro, Wim Henderickx, 2015-10-19, 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, Yakov Rekhter, John Drake, Lucy Yong, Linda Dunbar, 2015-10-19, 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. "Extranet Multicast in BGP/IP MPLS VPNs", Yakov Rekhter, Eric Rosen, Rahul Aggarwal, Yiqun Cai, Thomas Morin, 2015-12-21, Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide MVPN extranet service. "Ingress Replication Tunnels in Multicast VPN", Eric Rosen, Karthik Subramanian, Jeffrey Zhang, 2015-10-15, RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to- multipoint trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be "directly connected" to its child nodes. When a parent node has to send a multicast data packet to its child nodes, it does not use layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. "Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication", Jeffrey Zhang, Yakov Rekhter, Andrew Dolganow, 2015-10-16, RFC 6513 (Multicast in MPLS/BGP IP VPNs) describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a Service Provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers. "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Ali Sajassi, Dennis Cai, 2015-07-06, This document describes how Network Virtualization Overlay networks (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both. "FIB Reduction in Virtual Subnet", Xiaohu Xu, Christian Jacquenet, Truman Boyes, Brendan Fee, Wim Henderickx, 2015-07-30, Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution which is intended for building Layer3 network virtualization overlays within and/or between data centers. This document describes a mechanism for reducing the FIB size of PE routers in the Virtual Subnet context. "IP Prefix Advertisement in EVPN", Jorge Rabadan, Wim Henderickx, Senad Palislamovic, Aldrin Isaac, 2015-09-14, 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, Jeff Tantsura, Dirk Steinberg, Thomas Beckhaus, Jorge Rabadan, 2015-10-15, 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 single-segment and multi-segment PW signaling, and provides fast protection using data-plane prefix independent convergence upon node or link failure. "Multicast VPN state damping", Thomas Morin, Stephane Litkowski, Keyur Patel, Jeffrey Zhang, Robert Kebler, Jeffrey Haas, 2015-12-18, This document describes procedures to damp multicast VPN routing state changes and control the effect of the churn due to the multicast dynamicity in customer site. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control plane load increase in the core routing infrastructure. New procedures are proposed inspired from BGP unicast route damping principles, but adapted to multicast. "Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags", Eric Rosen, Thomas Morin, 2015-08-06, RFC6514 defines the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". This attribute contains an octet of "flags". Only one flag is defined in that RFC, but there is now a need to define additional flags. Since the RFC did not create a registry for the assignment of flag bits, this document updates the RFC by creating a registry for that purpose. This document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the PMSI Tunnel attribute. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2015-09-11, This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. "BGP as an MVPN PE-CE Protocol", Keyur Patel, Eric Rosen, Yakov Rekhter, 2015-10-05, When a Service Provider offers BGP/MPLS IP VPN service to its customers, RFCs 6513 and 6514 describe protocols and procedures that the Service Provider can use in order to carry the customer's IP multicast traffic from one customer site to others. BGP can be used to carry customer multicast routing information from one Provider Edge (PE) router to another, but it is assumed that PIM is running on the interface between a Customer Edge (CE) router and a PE router. This document specifies protocols and procedures that, under certain conditions, allow customer multicast routing information to carried between PE and CE via BGP. This can eliminate the need to run PIM on the PE-CE interfaces, potentially eliminating the need to run PIM on the PE routers at all. "Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution", Xiaohu Xu, Christian Jacquenet, Robert Raszuk, Truman Boyes, Brendan Fee, 2015-12-09, This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as Virtual Subnet, which can be used for building Layer 3 network virtualization overlays within and/or between data centers. "E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, Sami Boutros, Jim Uttaro, 2015-10-12, The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK] proposes a solution framework for supporting this service in MPLS networks. 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. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2015-07-22, [RFC6391] describes a mechanism that uses an additional label (Flow Label) in the MPLS label stack that allows Label Switch Routers to balance flows within Pseudowires at a finer granularity than the individual Pseudowires across the Equal Cost Multiple Paths (ECMPs) that exists within the Packet Switched Network (PSN). Furthermore,[RFC6391] defines the LDP protocol extensions required to synchronize the flow label states between the ingress and egress PEs when using the signaling procedures defined in the [RFC4447]. This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures defined in [RFC4761]. These protocol extensions are equally applicable to point-to-point L2VPNs defined in [RFC6624]. "Shortest Path Bridging, MAC Mode Support over EVPN", David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi, 2015-10-05, This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) can be combined with EVPN to interwork with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network attached an EVPN core while supporting full interworking between the different variations of Ethernet networks. "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler, 2015-12-09, 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. 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, 2015-09-11, 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, Sergio Murillo, 2015-10-13, The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, 2015-08-19, 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 Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2015-12-01, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. "Seamless Bidirectional Forwarding Detection (BFD) Use Case", Sam Aldrin, Manav Bhatia, Satoru Matsushima, Greg Mirsky, Nagendra Kumar, 2015-07-31, This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that extensions could be developed to allow for simplified detection of forwarding failures. "Seamless Bidirectional Forwarding Detection (S-BFD)", Nobo Akiya, Carlos Pignataro, David Ward, Manav Bhatia, Juniper Networks, 2015-06-19, This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS", Nobo Akiya, Carlos Pignataro, David Ward, 2015-06-20, This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. "Clarifications to RFC 5884", Vengada Govindan, Kalyani Rajaraman, Greg Mirsky, Nobo Akiya, Sam Aldrin, 2015-10-14, This document clarifies the procedures for establishing, maintaining and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given described in RFC5884. "BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks, 2015-11-17, 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)", Lianshu Zheng, Reshad Rahman, Juniper Networks, Mahesh Jethanandani, Greg Mirsky, 2015-08-19, 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, 2015-12-08, 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, 2015-07-29, 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, Jeffrey Zhang, Sam Aldrin, 2015-10-19, 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 OSPF protocol extension required for BIER with MPLS encapsulation. "Encapsulation for Bit Index Explicit Replication in MPLS Networks", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam Aldrin, 2015-08-31, 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 the BIER encapsulation to be used in an MPLS network. "Multicast VPN Using BIER", Eric Rosen, Mahesh Sivakumar, IJsbrand Wijnands, Sam Aldrin, Andrew Dolganow, Tony Przygienda, 2015-07-06, 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, 2015-08-03, 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, Jeffrey Zhang, 2015-10-17, 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, 2015-09-29, 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", Greg Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Juniper Networks, 2015-09-29, 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. Benchmarking Methodology (bmwg) ------------------------------- "Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence", Rajiv Papneja, Bhavani Parise, Susan Hares, Dean Lee, Ilya Varlashkin, 2015-01-16, BGP is widely deployed and used by several service providers as the default Inter AS routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP Benchmarking Methodology using existing BGP Convergence Terminology, RFC 4098. "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", Al Morton, 2015-09-23, 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 commodity off-the-shelf hardware. Version NOTES: Addressed Ramki Krishnan's comments on section 4.5, power, see that section (7/27 message to the list). Addressed Saurabh Chattopadhyay's 7/24 comments on VNF resources and other resource conditions and their effect on benchmarking, see section 3.4. Addressed Marius Georgescu's 7/17 comments on the list (sections 4.3 and 4.4). AND, comments from the extended discussion during IETF-93 BMWG session: Section 4.2: VNF footprint and auxilliary metrics (Maryam Tahhan), Section 4.3: Verification affect metrics (Ramki Krishnan); Section 4.4: Auxilliary metrics in the Matrix (Maryam Tahhan, Scott Bradner, others) "Data Center Benchmarking Terminology", Lucien Avramov, jhrapp@gmail.com, 2015-10-19, 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 equipment in the data center. "Data Center Benchmarking Methodology", Lucien Avramov, jhrapp@gmail.com, 2015-10-19, 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 IPv6 Neighbor Cache Behavior", William Cerveny, Ron Bonica, 2015-07-02, This document is a benchmarking instantiation of RFC 6583: "Operational Neighbor Discovery Problems" [RFC6583]. It describes a general testing procedure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes. "Benchmarking Methodology for IPv6 Transition Technologies", Marius, Gabor Lencse, 2015-10-14, 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, 2015-10-18, This document defines terminology for benchmarking an SDN Controller's performance. 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, 2015-10-18, This document defines the methodologies for benchmarking 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. Calendaring Extensions (calext) ------------------------------- "Calendar Availability", Cyrus Daboo, Mike Douglass, 2015-11-23, This document specifies a new iCalendar calendar component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including iTIP free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed. This document also defines extensions to CalDAV calendar-access and calendar-auto-schedule which specify how this new calendar component can be used when doing free-busy time evaluation in CalDAV. "New Properties for iCalendar", Cyrus Daboo, 2015-10-08, This document defines a set of new properties for iCalendar data as well as extending the use of some existing properties to the entire iCalendar object. Common Control and Measurement Plane (ccamp) -------------------------------------------- "RSVP-TE Signaling Extensions in support of Flexi-grid DWDM networks", Fatai Zhang, Xian Zhang, Adrian Farrel, Oscar Gonzalez de Dios, Daniele Ceccarelli, 2015-11-19, This memo describes the extensions to the Resource reSerVation Protocol Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. "Link Management Protocol Extensions for Grid Property Negotiation", Qilei Wang, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang, 2015-10-11, 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 Gonzalez de Dios, Daniele Ceccarelli, 2015-10-16, This memo 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, 2015-10-18, 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 Routing Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2015-10-18, 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 introduces an optional ISCD Availability sub-TLV in OSPF routing protocol. This extension can be used for route computation in a network that contains links with variable discrete bandwidth. "Ethernet Traffic Parameters with Availability Information", Hao Long, Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2015-10-18, 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 Extended Ethernet Bandwidth Profile TLV and an optional Availability sub-TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a label switching path (LSP) in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth. "IANA Allocation Procedures for OTN Signal Type Subregistry to the GMPLS Signaling Parameters Registry", Zafar Ali, Antonello Bonfanti, Matt Hartley, Fatai Zhang, 2015-09-10, IANA has defined an "OTN Signal Type" subregistry to the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. This draft proposes changes to the OTN Signal Type subregistry to include Specification Required policies, as defined in [RFC5226]. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTN", Zafar Ali, Antonello Bonfanti, Matt Hartley, Fatai Zhang, 2015-09-10, [RFC4328] and [RFC7139] provide the extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e and ODUflex. However, these specifications do not cover the additional signal types ODU1e, ODU3e1, and ODU3e2 mentioned in [G.Sup43]. This draft provides GMPLS signaling extensions for these additional signal types. "A Yang Data Model for WSON Optical Networks", Young Lee, Dhruv Dhody, Xian Zhang, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, 2015-12-15, 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 DWDM optical interface parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, 2015-10-19, 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 DMDM 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 a single channel DWDM interface The purpose is to identify the necessary information elements and processes to be used by control or management systems for further processing. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "CDN Interconnection Metadata", Ben Niven-Jenkins, Rob Murray, Matt Caulfield, Kevin Ma, 2015-10-19, The Content Delivery Networks Interconnection (CDNI) metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI metadata and the protocol for exchanging that metadata. "CDNI Logging Interface", Francois Le Faucheur, Gilles Bertrand, Iuniana Oprescu, Roy Peterkofsky, 2015-11-03, This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. "CDNI Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins, 2015-12-07, This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. "Request Routing Redirection Interface for CDN Interconnection", Ben Niven-Jenkins, Ray van Brandenburg, 2015-10-09, The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI Request Routing Redirection interface. "CDNI Request Routing: Footprint and Capabilities Semantics", Jan Seedorf, Jon Peterson, Stefano Previdi, Ray van Brandenburg, Kevin Ma, 2015-11-03, This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities Advertisement Interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines how these registries may be extended in the future. "URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le Faucheur, Ray van Brandenburg, Bill Downey, Michel Fisher, 2015-08-12, This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. Crypto Forum (cfrg) ------------------- "Hash-Based Signatures", David McGrew, Michael Curcio, 2015-10-19, 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, 2015-07-22, 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). "SPAKE2, a PAKE", Watson Ladd, 2015-08-16, This Internet-Draft describes SPAKE2, a secure, efficient password based key exchange protocol. "Elliptic Curves for Security", Adam Langley, Mike Hamburg, spt, 2015-10-09, This memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Aziz Mohaisen, 2015-07-03, 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, besides some special instantiations, 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 withstand attacks using quantum computers. "Requirements for PAKE schemes", Joern-Marc Schmidt, 2015-10-13, 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 and discusses their requirements. "Edwards-curve Digital Signature Algorithm (EdDSA)", Simon Josefsson, Ilari Liusvaara, 2015-12-09, The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described. The algorithm is instantiated with recommended parameters for the Curve25519 and Curve448 curves. An example implementation and test vectors are provided. NOTE: Anything not about Ed25519 in this document is premature and there is at least one FIXME that makes some things unimplementable. "Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API", Harry Halpin, Graham Steel, 2015-11-17, This overview document provides information on the current state of algorithms made available by the W3C Web Cryptography API, including whether protocols have security proofs or known weaknesses. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 2015-11-12, 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, 2015-10-18, This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano, 2015-10-19, This document provides an XML schema file for the definition of CLUE data model types. "CLUE Protocol data channel", Christer Holmberg, 2015-11-06, 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, 2015-08-05, This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. "CLUE protocol", Roberta Presta, Simon Romano, 2015-10-19, The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. 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) ------------------------------------- "Ogg Encapsulation for the Opus Audio Codec", Timothy Terriberry, Ron Lee, Ralph Giles, 2015-11-23, This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Congestion Exposure (conex) --------------------------- "Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements", Matt Mathis, Bob Briscoe, 2014-10-24, This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. "IPv6 Destination Option for Congestion Exposure (ConEx)", Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo, 2015-10-19, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. "TCP modifications for Congestion Exposure", Mirja Kuehlewind, Richard Scheffenegger, 2015-10-13, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). "Mobile Communication Congestion Exposure Scenario", Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Ying Zhang, Carlos Bernardos, 2015-10-18, This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. Constrained RESTful Environments (core) --------------------------------------- "Block-wise transfers in CoAP", Carsten Bormann, Zach Shelby, 2015-09-14, CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. "Representing CoRE Formats in JSON and CBOR", Kepeng Li, Akbar Rahman, Carsten Bormann, 2015-11-01, 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. Group Communication for the Constrained Application Protocol (RFC7390) defines a number of JSON formats for controlling communication between groups of nodes employing the Constrained Application Protocol (CoAP). In a similar vein, this specification defines CBOR variants of these formats. "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, 2015-10-19, 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 resources 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, 2015-10-19, This document defines a set of reusable REST resource design patterns suitable for use in constrained environments, based on IETF CoRE standards for information representation and information exchange. Interface types for Sensors, Actuators, Parameters, and resource Collections are defined using the "if" link attribute defined by CoRE Link Format [RFC6690]. Clients may use the "if" attribute to determine how to consume resources. Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. We also define conditional observation attributes that work with Link Bindings or with simple CoAP Observe [RFC7641]. "Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2015-07-03, This document provides reference information for implementing a proxy that performs translation between the HTTP protocol and the CoAP protocol, focusing on the reverse proxy case. It describes how a HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to a HTTP response. Furthermore, it defines a template for URI mapping and provides a set of guidelines for HTTP to CoAP protocol translation and related proxy implementations. "A TCP and TLS Transport for the Constrained Application Protocol (CoAP)", Carsten Bormann, Simon Lemay, Zebra Technologies, Hannes Tschofenig, 2015-11-19, The Hypertext Transfer Protocol (HTTP) was designed with TCP as the underlying transport protocol. The Constrained Application Protocol (CoAP), while inspired by HTTP, has been defined to make use of UDP instead of TCP. Therefore, reliable delivery and a simple congestion control and flow control mechanism are provided by the message layer of the CoAP protocol. A number of environments benefit from the use of CoAP directly over a reliable byte stream such as TCP, which already provides these services. This document defines the use of CoAP over TCP as well as CoAP over TLS. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Encoded Message Syntax", Jim Schaad, 2015-12-16, 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 the basic security services defined for this data format. This document specifies procesing for signatures, message authentication codes, and encryption using CBOR. This document also specifies a represention for cryptographic keys using CBOR. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 2015-08-27, 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 DANE (RFC 6698) does for TLS. "Using DANE to Associate OpenPGP public keys with email addresses", Paul Wouters, 2015-10-19, OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. This document specifies a method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be send unencrypted. 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, 2015-12-15, 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. Dynamic Host Configuration (dhc) -------------------------------- "Access Network Identifier Option in DHCP", Shwetha Bhandari, Sri Gundavelli, Mark Grayson, Bernie Volz, Jouni Korhonen, 2015-08-31, This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. "Customizing DHCP Configuration on the Basis of Network Topology", Ted Lemon, Tomek Mrugalski, 2015-10-19, DHCP servers have evolved over the years to provide significant functionality beyond that which is described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and makes recommendations as to how they can be used. "Secure DHCPv6", Sheng Jiang, Lishan Li, Yong Cui, Tatuya Jinmei, Ted Lemon, Dacheng Zhang, 2015-12-10, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not being secured, DHCPv6 is vulnerable to various attacks. This document analyzes the security issues of DHCPv6 and specifies a secure DHCPv6 mechanism for the authentication and encryption between DHCPv6 client and DHCPv6 server. "Privacy considerations for DHCPv4", Sheng Jiang, Suresh Krishnan, Tomek Mrugalski, 2015-08-26, DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. "Privacy considerations for DHCPv6", Suresh Krishnan, Tomek Mrugalski, Sheng Jiang, 2015-08-26, DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document described the privacy issues associated with the use of DHCPv6 by the Internet users. It is intended to be an analysis of the present situation and doe not propose any solutions. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael Richardson, Sheng Jiang, Ted Lemon, 2015-10-19, The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be used separately or concurrently with the latter to obtain configuration parameters. This document updates the original DHCPv6 specification (RFC 3315) and incorporates RFC 3633, RFC 3736, RFC 7083, and RFC 7550. "Anonymity profile for DHCP clients", Christian Huitema, Tomek Mrugalski, Suresh Krishnan, 2015-10-02, Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. This draft updates RFC4361. "DHCPv6 Relay Initiated Release", Sunil Gandhewar, 2015-10-01, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is initiated by a DHCPv6 client. A DHCPv6 server can force DHCPv6 client to send RENEW or INFORMATION-REQUEST by sending a RECONFIGURE message. There may be multiple DHCPv6 network devices connected in between a DHCPv6 client and a server, each one reserving resources for the DHCPv6 client. There are no DHCPv6 messages that a relay can initiate in order to control the client binding. A DHCPv6 client may not always send a RELEASE message when it no longer needs the IPv6 address or prefix and network resources for the associated services it is using. This document specifies a way to request release to be initiated by an intermediate DHCPv6 network device, e.g. DHCPv6 relay, on behalf of DHCPv6 client. This helps to relinquish network resources sooner than the lease expiration time. "DHCP Relay Initiated Release", Sunil Gandhewar, 2015-10-01, The Dynamic Host Configuration Protocol (DHCP) is initiated by a DHCP client. A DHCP server can force DHCP client to send DHCPRENEW by sending a DHCPFORCERENEW message. There may be multiple DHCP network devices connected in between a DHCP client and a server, each one reserving resources for the DHCP client. There are no DHCP messages that a relay can initiate in order to control the client binding. A DHCP client may not always send a DHCPRELEASE message when it no longer needs the IP address and network resources for the associated services it is using. This document specifies a way to request release message to be initiated by an intermediate DHCP network device, e.g. DHCP relay, on behalf of DHCP client. This helps to relinquish network resources sooner than the lease expiration time. "YANG Data Model for DHCPv6 Configuration", Yong Cui, Hao Wang, Linhui Sun, Ted Lemon, Ian Farrer, 2015-10-16, There has no unified method to configure DHCPv6 server ,relay and client itself, always pre-configured manually by operators. IETF netmod WG has developed a general data model for NETCONF protocol, YANG data model [RFC6020]. This document defines a YANG data model for the configuration and management of DHCPv6 server, DHCPv6 relay and DHCPv6 client. With this model, the operators can configure and manage the devices by using NETCONF. "DHCPv6 Failover Protocol", Tomek Mrugalski, Kim Kinnear, 2015-12-24, 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 for DHCPv6 failover, a mechanism for running two servers on the same network 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). DTLS In Constrained Environments (dice) --------------------------------------- "TLS/DTLS Profiles for the Internet of Things", Hannes Tschofenig, Thomas Fossati, 2015-10-18, A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram TLS (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in Internet of Things products that can easily be solved by using these well-researched and widely deployed Internet security protocols. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2015-07-06, 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, 2015-08-31, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) 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, 2015-10-14, This specification documents an extension to the 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, 2015-10-14, This document defines a mechanism for sharing of Diameter load information. RFC 7068 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. The 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. "Diameter Routing Message Priority", Steve Donovan, 2015-11-11, When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Interoperability Issues Between DMARC and Indirect Email Flows", Franck Martin, Eliot Lear, Tim Draegen, Elizabeth Zwicky, Kurt Andersen, 2015-12-08, DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Distributed Mobility Management (dmm) ------------------------------------- "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Jerome Marcon, 2015-10-19, Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). "On Demand Mobility Management", Alper Yegin, Kisuk Kweon, Jinsung Lee, Jungshin Park, Danny Moses, 2015-11-04, 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", Marco Liebsch, Satoru Matsushima, Sri Gundavelli, Danny Moses, 2015-07-06, The specification as per this document supports the separation of the Control-Plane for mobility- and session management from the actual Data-Plane. The protocol semantics abstract from the actual details for the configuration of Data-Plane nodes and apply between a Client function, which is used by an application of the mobility Control- Plane, and an Agent function, which is associated with the configuration of Data-Plane nodes according to the policies issued by the mobility Control-Plane. The scope of the policies comprises forwarding rules and treatment of packets in terms of encapsulation, IP address re-writing and QoS. Additional protocol semantics are described to support the maintenance of the Data-Plane path. "MAG Multipath Binding Option", Pierrick Seite, Alper Yegin, Sri Gundavelli, 2015-12-16, 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, 2015-12-16, This specification defines a new extension, LMA-Controlled-MAG- Session-Params to Proxy Mobile IPv6. This option can be used by the LMA in PMIPv6 signaling for notifying the MAG to conform to various parameters contained in this extension. "Home Network Prefix Renumbering in PMIPv6", Zhiwei Yan, Jong-Hyouk Lee, XiaoDong Lee, 2015-12-16, In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its initial attachment for the Home Address (HoA) configuration. During the movement of the MN, this prefix remains unchanged and in this way it is unnecessary for the MN to reconfigure its HoA and reconnect the ongoing communications. However, the current protocol (RFC5213) does not specify related operations to support the MN to timely receive and use a new HNP when the allocated HNP changes. In this draft, a solution to support the HNP renumbering is proposed, as an update of RFC5213. Domain Name System Operations (dnsop) ------------------------------------- "DNS Scoped Data Through '_Underscore' Attribute Leaves", dcrocker, 2015-11-14, 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. "Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.", Mark Andrews, 2015-10-11, RFC6598 specified that: "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure." This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries accidently leaking to the global DNS infrastructure. "DNSSEC Roadblock Avoidance", Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy, 2015-07-01, This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. "The edns-tcp-keepalive EDNS0 Option", Paul Wouters, Joe Abley, Sara Dickinson, Ray Bellis, 2015-10-21, DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for fallback and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. "Chain Query requests in DNS", Paul Wouters, 2015-11-16, This document defines an EDNS0 extension that can be used by a security-aware validating Resolver configured to use a Forwarder to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source IP verified transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused in amplification attacks. "DNS query name minimisation to improve privacy", Stephane Bortzmeyer, 2015-11-29, This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. "Client Subnet in DNS Queries", Carlo Contavalli, Wilmer van der Gaast, tale, Warren Kumari, 2015-12-15, This document defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent response can be cached. "Domain Name System (DNS) Cookies", Donald Eastlake, Mark Andrews, 2015-12-24, DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) "DNS Transport over TCP - Implementation Requirements", John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, Duane Wessels, 2015-12-17, This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC5966 and therefore updates RFC1035 and RFC1123. "Aggressive use of NSEC/NSEC3", Kazunori Fujiwara, Akira Kato, 2015-10-19, While DNS highly depends on cache, its cache usage of non-existence information was limited to exact matching. This draft proposes the aggressive use of a NSEC/NSEC3 resource record, which is able to express non-existence of range of names authoritatively. With this proposal, shorter latency to many of negative responses is expected as well as some level of mitigation of random sub-domain attacks (referred to as "Water Torture" attacks). It is also expected that non-existent TLD queries to Root DNS servers will decrease. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2015-09-30, This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts or for names that have no meaning in a global context. It also provides advice and guidance to developers developing alternate namespaces. [ Ed note: This document lives in GitHub at: https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and pull requests happily accepted. ] "DNS message checksums", Mukund Sivaraman, 2015-10-13, This document describes a method for a client to be able to verify that IP-layer PDU fragments of a UDP DNS message have not been spoofed by an off-path attacker. "Ordering of RRSets in DNS Messages", Joe Abley, 2015-10-09, The existing Domain Name System (DNS) specifications lack some clarity in their description of the process by which individual sections of a DNS message are constructed. This document updates RFC 1034 and RFC 1035 to provide a clearer specification, consistent with deployed implementations. "Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE", Tony Finch, 2015-11-10, This memo describes how to do IN-ADDR.ARPA delegation on any non- octet boundary, and how to consolidate reverse DNS for multiple address blocks into one zone. It also clarifies the behaviour of dynamic reverse DNS UPDATE clients. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2015-12-22, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the ip6.arpa zone for IPv6 address space assigned to many customers. "Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY", Joe Abley, Ólafur Guðmundsson, Marek Majkowski, 2015-11-05, 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, 2015-11-30, 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 classes of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other similar 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. "The EDNS Key Tag Option", Duane Wessels, 2015-12-09, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a way for validating end-system resolvers to signal to a server which keys are referenced in their chain-of-trust. The extensions allow zone administrators to monitor the progress of rollovers in a DNSSEC- signed zone. "Managing DS records from parent via CDS/CDNSKEY", Ólafur Guðmundsson, Paul Wouters, 2015-12-14, RFC7344 specifies how DNS trust can be maintained in-band between parent and child. There are two features missing in that specification: initial trust setup and removal of trust anchor. This document addresses both these omissions. Changing a domain's DNSSEC status can be a complicated matter involving many parties. Some of these parties, such as the DNS operator, might not even be known by all organisations involved. The inability to enable or disable DNSSEC via in-band signalling is seen as a problem or liability that prevents DNSSEC adoption at large scale. This document adds a method for in-band signalling of DNSSEC status changes. Initial trust is considered a much harder problem, this document will seek to clarify and simplify the initial acceptance policy. "NXDOMAIN really means there is nothing underneath", Stephane Bortzmeyer, Shumon Huque, 2015-12-27, This document states clearly that when a DNS resolver receives a response with response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DNSOP (DNS Operations) group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1]. This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it updates both of them. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "Hybrid Unicast/Multicast DNS-Based Service Discovery", Stuart Cheshire, 2015-11-05, Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require excessively large multicast domains, but requires that the relevant data be available in the Unicast DNS namespace. This can be achieved by manual DNS configuration (as has been done for many years at IETF meetings to advertise the IETF Terminal Room printer) but this is labor intensive, error prone, and requires a reasonable degree of DNS expertise. The Unicast DNS namespace can be populated with the required data automatically by the devices themselves, but that requires configuration of DNS Update keys on the devices offering the services, which has proven onerous and impractical for simple devices like printers and network cameras. Hence, to facilitate efficient and reliable DNS-Based Service Discovery, a compromise is needed that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. "On Interoperation of Labels Between DNS and Other Resolution Systems", Andrew Sullivan, 2015-11-01, 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, 2015-11-05, 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. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Stephane Fouant, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia, 2015-10-19, This document delineates principal and ancillary use cases for DDoS Open Threat Signaling (DOTS), a communications protocol intended to facilitate the programmatic, coordinated mitigation of Distributed Denial of Service (DDoS) attacks via a standards-based mechanism. DOTS is purposely designed to support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. "DDoS Open Threat Signaling Requirements", Andrew Mortensen, Robert Moskowitz, Tirumaleswar Reddy, 2015-10-19, This document defines the requirements for the DDoS Open Threat Signaling (DOTS) protocols coordinating attack response against Distributed Denial of Service (DDoS) attacks. DNS PRIVate Exchange (dprive) ----------------------------- "DNS over DTLS (DNSoD)", Tirumaleswar Reddy, Dan Wing, Prashanth Patil, 2015-11-24, DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over port 853. "DNS over TLS: Initiation and Performance Considerations", Zi, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, Paul Hoffman, 2015-12-07, This document describes the use of TLS to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7258. In addition, this document specifies two usage profiles for DNS-over-TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. Note: this document was formerly named draft-ietf-dprive-start-tls-for-dns. Its name has been changed to better describe the mechanism now used. Please refer to working group archives under the former name for history and previous discussion. [RFC Editor: please remove this paragraph prior to publication] "The EDNS(0) Padding Option", Alexander Mayrhofer, 2015-11-24, This document specifies the EDNS(0) 'Padding' option, which allows DNS clients and servers to pad request and response messages by a variable number of octets. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Session Peering Provisioning (SPP) Protocol over SOAP", Kenneth Cartwright, Vikas Bhatia, Jean-Francois Mule, Alexander Mayrhofer, 2015-07-22, The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision session establishment data into Session Data Registries and SIP Service Provider data stores. To utilize this framework one needs a substrate protocol. Given that Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise, and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF based protocol. "Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright, Vikas Bhatia, Syed Ali, David Schwartz, 2015-08-12, This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session establishment. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane, 2015-11-25, 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. Delay-Tolerant Networking (dtnrg) --------------------------------- "DTN IP Neighbor Discovery (IPND)", Daniel Ellard, Richard Altmann, Alex Gladd, Ronald Velt, Daniel Brown, 2015-11-10, Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement "beacons." Beacon messages are addressed to an IP unicast, multicast, or broadcast destination to discover specified or unspecified remote neighbors, or unspecified local neighbors in the topology, e.g. within wireless range. IPND beacons advertise neighbor availability by including the DTN node's canonical endpoint identifier. IPND beacons optionally include service availability and parameters. In this way, neighbor discovery and service discovery may be coupled or decoupled as required. Once discovered, new neighbor pairs use advertised availabilities to connect, exchange routing information, etc. This document describes DTN IPND. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 2015-08-11, RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. "Additional Data Related to an Emergency Call", Randall Gellens, Brian Rosen, Hannes Tschofenig, Roger Marshall, James Winterbottom, 2015-10-12, When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much as possible of the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. "Next-Generation Pan-European eCall", Randall Gellens, Hannes Tschofenig, 2015-11-05, 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. eCall deployment is required in the very near future in European Union member states, and eCall (and eCall- compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. "Next-Generation Vehicle-Initiated Emergency Calls", Randall Gellens, Brian Rosen, Hannes Tschofenig, 2015-11-05, 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 Content Type and an 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). 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 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 eCall document, with the differences being that this document makes the MSD data set optional and VEDS mandatory. This document also discusses legacy (curcuit-switched) ACN systems and their migration to next-generation emergency calling. "A LoST extension to return complete and similar location info", Roger Marshall, Jeff Martin, Brian Rosen, 2015-10-19, This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as compilation of ca type xml elements within the existing LoST findServiceResponse message structure. "A Routing Request Extension for the HELD Protocol", James Winterbottom, Hannes Tschofenig, Laura Liess, 2015-12-09, For cases where location servers have access to emergency routing information they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HELD protocol, updating [RFC5985], to support this funciton. Extensible Provisioning Protocol Extensions (eppext) ---------------------------------------------------- "Key Relay Mapping for the Extensible Provisioning Protocol", M. Groeneweg, Antoin Verschuren, rikribbers, 2015-12-07, This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC5730. This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)", James Gould, Wil Tan, Gavin Brown, 2015-11-02, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. "Mark and Signed Mark Objects Mapping", Gustavo Lozano, 2015-09-28, This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the sunrise phase of generic Top Level Domains (gTLDs). "TMCH functional specifications", Gustavo Lozano, 2015-10-09, This document describes the requirements, the architecture and the interfaces between the Trademark Clearing House (TMCH) and Domain Name Registries as well as between the TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. Global Access to the Internet for All (gaia) -------------------------------------------- "Alternative Network Deployments. Taxonomy, characterization, technologies and architectures", Jose Saldana, Andres Arcia-Moret, Bart Braem, Ermanno Pietrosemoli, Arjuna Sathiaseelan, Marco Zennaro, 2015-11-13, This document presents a taxonomy of "Alternative Network deployments", and a set of definitions and shared properties. It also surveys the technologies employed in these network deployments, and their differing architectural characteristics. The term "Alternative Network Deployments" includes a set of network access models that have emerged in the last decade with the aim of bringing Internet connectivity to people, using topological, architectural and business models different from the so-called "traditional" ones, where a company deploys or leases the network infrastructure for connecting the users, who pay a subscription fee to be connected and make use of it. Several initiatives throughout the world have built large scale Alternative Networks, using predominantly wireless technologies (including long distance) due to the reduced cost of using the unlicensed spectrum. Wired technologies such as fiber are also used in some of these alternate networks. The emergence of these networks can be motivated by different causes such as the reluctance, or the impossibility, of network operators to provide wired and cellular infrastructures to rural/remote areas. In these cases, the networks have self sustainable business models that provide more localized communication services as well as Internet backhaul support through peering agreements with traditional network operators. Some other times, networks are built as a complement and an alternative to commercial Internet access provided by "traditional" network operators. The present classification considers different existing network models such as Community Networks, which are self-organized and decentralized networks wholly owned by the community; networks owned by individuals who act as Wireless Internet Service Providers (WISPs); networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, and finally there are networks that provide connectivity by sharing wireless resources of the users. Different criteria are used in order to build a classification as e.g., the ownership of the equipment, the way the network is organized, the participatory model, the extensibility, if they are driven by a community, a company or a local stakeholder (public or private), etc. According to the developed taxonomy, a characterization of each kind of network is presented in terms of specific network characteristics related to architecture, organization, etc. 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, 2013-10-11, 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 about any IPR constraints on a technical proposal as possible. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details 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 memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. "IETF Anti-Harassment Procedures", Pete Resnick, Adrian Farrel, 2015-11-03, IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, social events, or on mailing lists. This document lays out procedures for managing and enforcing this policy. This document updates RFC 2418 by defining new Working Group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. "Tracking Reviews of Documents", Robert Sparks, Tero Kivinen, 2015-08-07, Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows. "Statement of Work for Extensions to the IETF Datatracker for Author Statistics", Russ Housley, 2015-09-23, This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors. Geographic JSON (geojson) ------------------------- "The GeoJSON Format", H. Butler, M. Daly, A. Doyle, Sean Gillies, T. Schaub, 2015-11-16, GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. This document recommends a single coordinate reference system based on WGS 84. Other coordinate reference systems are not recommended. Global Routing Operations (grow) -------------------------------- "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 2015-11-12, This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. "Internet Exchange BGP Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 2015-06-08, The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. "Impact of BGP filtering on Inter-Domain Routing Policies", Camilo Cardona, P. Francois, Paolo Lucente, 2015-11-07, This document describes how unexpected traffic flows can emerge across an autonomous system, as the result of other autonomous systems filtering, or restricting the propagation of more specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it. "Problem Definition and Classification of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Danny McPherson, Eric Osterweil, Brian Dickson, 2015-10-12, A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date we have lacked a common definition of the term. In this document, we provide a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, we attempt to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. We aim to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Lars Eggert, 2015-06-30, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC5203. "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 2015-12-17, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu, 2015-12-14, 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. "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Julien Laganier, 2015-12-14, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. "Host Mobility with the Host Identity Protocol", Thomas Henderson, Christian Vogt, Jari Arkko, 2015-07-22, This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 2015-07-23, 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. "Host Multihoming with the Host Identity Protocol", Thomas Henderson, Christian Vogt, Jari Arkko, 2015-07-22, This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. "Host Identity Protocol Certificates", Tobias Heer, Samu Varjonen, 2015-12-09, The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter. This document updates RFC7401 and obsoletes RFC6253. Home Networking (homenet) ------------------------- "Home Networking Control Protocol", Markus Stenberg, Steven Barth, Pierre Pfister, 2015-11-26, This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol which supports routing based on both source and destination address. "Outsourcing Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2015-09-23, RFC7368 'IPv6 Home Networking Architecture Principles' section 3.7 describes architecture principles related to naming and service discovery in residential home networks. Customer Edge Routers and other Customer Premises Equipment (CPEs) are designed to provide IP connectivity to home networks. Most CPEs assign IP addresses to the nodes of the home network which makes them good candidates for hosting the naming service. IPv6 provides global connectivity, and nodes from the home network will be reachable from the global Internet. As a result, the naming service is expected to be exposed on the Internet. However, CPEs have not been designed to host such a naming service exposed on the Internet. Running a naming service visible on the Internet may expose the CPEs to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. In addition, regular end users may not understand, or possess the necessary skills to be able to perform, DNSSEC management and configuration. Misconfiguration may also result in naming service disruption, thus these end users may prefer to rely on third party name service providers. This document describes a homenet naming architecture, where the CPEs manage the DNS zones associated with its own home network, and outsource elements of the naming service (possibly including DNSSEC management) to a third party running on the Internet. "DHCPv6 Options for Homenet Naming Architecture", Daniel Migault, Tomek Mrugalski, Chris Griffiths, Ralf Weber, Wouter Cloetens, 2015-10-19, Customer Premises Equipment (CPE) devices are usually constrained devices with reduced network and CPU capabilities. As such, a CPE exposing the authoritative naming service for its home network on the Internet may become vulnerable to resource exhaustion attacks. One way to avoid exposing CPE is to outsource the authoritative service to a third party, e.g. ISP. Such an outsource requires setting up an architecture which may be inappropriate for most end users. This document defines DHCPv6 options so any agnostic CPE can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. "Distributed Node Consensus Protocol", Markus Stenberg, Steven Barth, 2015-11-01, This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol, and must be combined with a specific profile to make a complete implementable protocol. "Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes", Markus Stenberg, 2015-10-15, This document describes how a proxy functioning between Unicast DNS- Based Service Discovery and Multicast DNS can be automatically configured using an arbitrary network-level state sharing mechanism. "Homenet Routing Consensus Call", Ray Bellis, Mark Townsley, 2015-11-18, In order to support arbitrary network topologies and multi-homing the IETF Homenet Architecture [RFC7368] requires that a routing protocol operates inside each home network. For interoperability reasons it is necessary for there be a single "mandatory to implement" routing protocol. With the Homenet Working Group unable to reach clear consensus on which protocol that should be the Working Group Chairs (with the support of the Internet Area Director) declared rough consensus that the chosen protocol is BABEL [RFC6126]. This document confirms this decision for the record. Hypertext Transfer Protocol Authentication (httpauth) ----------------------------------------------------- "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, lef, Yuichi Ioku, 2015-07-06, This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. "HTTP Authentication Extensions for Interactive Clients", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, lef, Yuichi Ioku, 2015-07-06, This document specifies a few extensions of HTTP authentication framework for interactive clients. Recently, fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. "Salted Challenge Response (SCRAM) HTTP Authentication Mechanism", Alexey Melnikov, 2015-12-16, This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, lef, Yuichi Ioku, 2015-07-06, This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Hypertext Transfer Protocol (httpbis) ------------------------------------- "HTTP Alternative Services", mnot, Patrick McManus, Julian Reschke, 2015-12-14, This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. "Opportunistic Security for HTTP", mnot, Martin Thomson, 2015-12-17, This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. "First-Party-Only Cookies", Mike West, Mark Goodwin, 2015-09-08, This document updates RFC6265 by defining a "First-Party-Only" attribute which allows servers to assert that a cookie ought to be sent only in a "first-party" context. This assertion allows user agents to mitigate the risk of cross-origin information leakage, and provides some minimal protection against cross-site request forgery attacks. "An HTTP Status Code to Report Legal Obstacles", Tim Bray, 2015-11-10, This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at [1]. Working Group information can be found at [2] and [3]; source code and issues list for this draft can be found at [4]. "The ORIGIN HTTP/2 Frame", mnot, Erik Nygren, 2015-07-20, This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 2015-10-02, By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. "The Key HTTP Response Header Field", Roy Fielding, mnot, 2015-10-18, The 'Key' header field for HTTP responses allows an origin server to describe the secondary cache key ([RFC7234], section 4.1) for a resource, by conveying what is effectively a short algorithm that can be used upon later requests to determine if a stored response is reusable for a given request. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending request header fields in order to reduce the risk of fingerprinting. "HTTP Client Hints", Ilya Grigorik, 2015-11-24, 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 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, 2015-12-23, This memo introduces a content-coding for HTTP that allows message payloads to be encrypted. Interface to the Routing System (i2rs) -------------------------------------- "An Architecture for the Interface to the Routing System", Alia Atlas, Joel Halpern, Susan Hares, David Ward, Tom Nadeau, 2015-12-23, This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). "Interface to the Routing System Problem Statement", Alia Atlas, Tom Nadeau, David Ward, 2015-12-18, Traditionally, routing systems have implemented routing and signaling (e.g. MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. With the advent of highly dynamic data center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision- making from the router itself, the need has emerged to more dynamically manage and program routing systems in order to control routing information and traffic paths and to extract network topology information, traffic statistics, and other network analytics from routing systems. This document proposes meeting this need via an Interface to the Routing System (I2RS). "Routing Information Base Info Model", Nitin Bahadur, Sriganesh Kini, Jan Medved, 2015-10-19, Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model. 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. "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", Joe Clarke, Gonzalo Salgueiro, Carlos Pignataro, 2015-12-18, This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. "Requirements for Subscription to YANG Datastores", Eric Voit, Alex Clemm, Alberto Prieto, 2015-10-02, This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh Kini, Nitin Bahadur, 2015-11-22, 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", Alex Clemm, Jan Medved, Robert Varga, Tony Tkacik, Nitin Bahadur, Hariharan Ananthakrishnan, 2015-12-08, 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-2 Network Topologies", Jie Dong, Xiugang Wei, 2015-12-22, This document defines a YANG data model for Layer 2 network topologies. "A YANG Data Model for Layer 3 Topologies", Alex Clemm, Jan Medved, Robert Varga, Tony Tkacik, Xufeng Liu, Igor Bryskin, Aihua Guo, Hariharan Ananthakrishnan, Nitin Bahadur, Vishnu Pavan Beeram, 2015-12-11, This document defines a YANG data model for layer 3 network topologies. "I2RS Ephemeral State Requirements", Jeffrey Haas, Susan Hares, 2015-09-02, This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. "I2RS Security Related Requirements", Susan Hares, Daniel Migault, Joel Halpern, 2015-09-02, This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. "I2RS Environment Security Requirements", Daniel Migault, Joel Halpern, Susan Hares, 2015-10-07, This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result, the requirements provided in this document are intended to provide good security practise so I2RS can be securely deployed and operated. These security requirements are designated as environment security requirements as opposed to the protocol security requirements. The reason to have separate document is that protocol security requirements are intended to help the design of the I2RS protocol whether the environment requirements are rather intended for deployment or implementations. Internet Architecture Board (iab) --------------------------------- "Technical Considerations for Internet Service Blocking and Filtering", Richard Barnes, Alissa Cooper, Olaf Kolkman, Dave Thaler, Erik Nordmark, 2015-11-01, The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering," the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches. "The 'XML2RFC' version 2 Vocabulary", Julian Reschke, 2015-09-16, This document defines the 'XML2RFC' version 2 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. Version 2 represents the current state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the XML2RFC mailing list (xml2rfc@ietf.org), which has its home page at . "Digital Preservation Considerations for the RFC Series", Heather Flanagan, 2015-07-29, 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, 2015-10-14, The IAB has published [RFC7624] in response to several revelations of pervasive attack on Internet communications. In this document we survey the mitigations to those threats which are currently available or which might plausibly be deployed. We discuss these primarily in the context of Internet protocol design, focusing on robustness to pervasive monitoring and avoidance of unwanted cross-mitigation impacts. "Out With the Old and In With the New: Planning for Protocol Transitions", Dave Thaler, 2015-10-14, Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions, throughout the protocol stack, from one protocol or technology to another. 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. "On RFC Streams, Headers, and Boilerplates", Joel Halpern, Leslie Daigle, Olaf Kolkman, IAB, 2015-12-12, RFC documents contain a number of fixed elements such as the title page header, standard boilerplates and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats. "Problems with the Public Key Infrastructure (PKI) for the World Wide Web", Russ Housley, Karen O'Donoghue, 2015-12-09, This document describes the technical and non-technical problems with the current Public Key Infrastructure (PKI) used for the World Wide Web. Some potential technical improvements are considered, and some non-technical approaches to improvements are discussed. "The 'XML2RFC' version 3 Vocabulary", Paul Hoffman, 2015-12-23, This document defines the "XML2RFC" version 3 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 2629 and its expected followup, draft-iab-xml2rfc. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the rfc-interest mailing list (rfc-interest@rfc-editor.org), which has its home page at . Planning for the IANA/NTIA Transition (ianaplan) ------------------------------------------------ "Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries", Eliot Lear, Russ Housley, 2015-01-06, The U.S. NTIA has solicited a request from ICANN to propose how the NTIA should end its oversight of the IANA functions. After broad consultations, ICANN has in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for thre three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It is meant to be included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. Interactive Connectivity Establishment (ice) -------------------------------------------- "ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", Paal-Erik Martinsen, Tirumaleswar Reddy, Prashanth Patil, 2015-10-19, 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, Jonathan Rosenberg, 2015-12-21, 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, 2015-12-10, This document describes 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. This mechanism is called "trickle ICE". Information-Centric Networking (icnrg) -------------------------------------- "Information-centric Networking: Evaluation Methodology", Kostas Pentikousis, Borje Ohlman, Elwyn Davies, Spiros Spirou, Gennaro Boggia, 2015-10-19, This document surveys the evaluation tools currently available to researchers in the information-centric networking (ICN) area and provides suggestions regarding methodology and metrics. Further, this document sheds some light on the impact of ICN on network security. "Adaptive Video Streaming over ICN", Stefan Lederer, cedric.westphal@huawei.com, Christopher Mueller, Andrea Detti, Daniel Corujo, Jianping Wang, Marie-Jose Montpetit, Niall Murray, aytav.azgin, Shucheng LIU, Christian Timmerer, Daniel Posch, 2015-12-09, This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Network (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented, covering a wide range of scenarios: we look at how to evolve DASH to work over ICN, and leverage the recent ISO/IEC MPEG Dynamic Adaptive Streaming over HTTP (DASH) standard; we consider layered encoding over ICN; P2P mechanisms introduce distinct requirements for video and we look at how to adapt Peer to Peer Streaming Protocol (PPSP) for ICN; IPTV adds delay constraints, and this will create more stringent requirements over ICN as well. As part of the discussion on video, we discuss DRMs in ICN. Finally, in addition to consider how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN specific video streaming mechanisms. "ICN Research Challenges", Dirk Kutscher, Suyong Eum, Kostas Pentikousis, Ioannis Psaras, Daniel Corujo, Damien Saucez, Thomas Schmidt, Matthias Waehlisch, 2015-12-15, This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user-mobility, multicast and in-network caching. This document describes the the research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). "CCNx Semantics", marc.mosko@parc.com, 2015-06-29, This document describes the core concepts of the CCNx architecture and presents a minimum network protocol based on two messages: Interest and Content Object. 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. It indicates to the previous hop that the current system will not respond to the Interest. "CCNx Messages in TLV Format", marc.mosko@parc.com, 2015-06-29, This document specifies the encoding of CCNx messages using a TLV Packet specification. CCNx messages follow the CCNx Semantics specification. This document defines the TLV types used by each message element and the encoding of each value. Inter-Domain Routing (idr) -------------------------- "Analysis of Existing work for I2NSF", Susan Hares, Keyur Patel, 2015-07-06, 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. "Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 2015-12-11, This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, 2015-07-02, This document proposes a solution for BGP route reflectors to facilitate the application of closest exit point policy (hot potato routing) without requiring further state or any new features to be placed on the RR clients. 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 for hot potato routing. 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 neighbour. "Extended Message support for BGP", Keyur Patel, David Ward, Randy Bush, 2015-07-24, 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 in RFC4271 by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 2015-11-25, 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, 2015-11-01, 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, 2015-11-04, 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 to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. "Automatic Route Target Filtering for legacy PEs", Pradosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 2015-10-16, 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]. "Internet Exchange BGP Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 2015-10-19, This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray, 2015-10-16, In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). "Inter-domain SLA Exchange", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 2015-11-01, 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, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling, which can help to simplify some of the complexities, where BGP is available as the routing protocol. This document defines 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. "Distribution of MPLS Traffic Engineering (TE) LSP State using BGP", Jie Dong, Mach Chen, Hannes Gredler, Stefano Previdi, Jeff Tantsura, 2015-12-03, This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement, and network visualization. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2015-11-13, There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 2015-10-07, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "Advertising Per-node Admin Tags in BGP Link-State Advertisements", P. Sarkar, Hannes Gredler, Stephane Litkowski, 2015-11-10, This document describes the protocol extensions to collect per-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 per-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 for L2 VPN", Hao Weiguo, LQD, Stephane Litkowski, Shunwan Zhuang, 2015-11-15, 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, 2015-12-07, 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 Egress Peer Engineering BGP-LS Extensions", Stefano Previdi, Clarence Filsfils, Saikat Ray, Keyur Patel, Jie Dong, Mach Chen, 2015-12-21, 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 egress point topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient Egress Point Engineering policies and strategies. "Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen, 2015-11-22, 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]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. 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. "Registered Wide BGP Community Values", Robert Raszuk, Jeffrey Haas, 2015-11-22, Communicating various routing policies via route tagging plays an important role in external BGP peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Thomas King, 2015-07-06, 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 BGP next hop cost to signal the state of the data link to the route server(s). "BGP Model for Service Provider Networks", Anees Shaikh, Rob Shakir, Keyur Patel, Susan Hares, Kevin D'Souza, Deepak Bansal, Alex Clemm, Alex, Mahesh Jethanandani, Xufeng Liu, 2015-07-06, This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Brian Dickson, Keyur Patel, Andrei Robachevsky, 2015-10-19, In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don't offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed. "Internet Exchange Route Server - Implementation Report", Elisa Jasinska, 2015-08-14, This document provides a survey of Internet Exchange Route Server implementations. "Inter-domain SLA Exchange Implementation Report", Shitanshu Shah, Keyur Patel, 2015-08-16, This document is a report of implementations based on [IDR-SLA]. [IDR-SLA] introduces a new BGP attribute to exchange QoS SLA parameters between BGP peers. Current status of the implementation report covers Cisco implementation on 2 different OS, ExaBGP implementation and inter-operability results between them. "The BGP Tunnel Encapsulation Attribute", Eric Rosen, Keyur Patel, Gunter Van de Velde, 2015-12-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, 2015-12-21, 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. "Distribution of TRILL Link-State using BGP", Hao Weiguo, Donald Eastlake, Susan Hares, Sujay Gupta, Muhammad Durrani, Li Yizhou, 2015-09-09, This draft describes a TRILL link state and MAC address reachability information distribution mechanism using a BGP LS extension. External components such as an SDN Controller can use the information for topology visibility, troubleshooting, network automation, etc. IMAP APPEND Extensions (imapapnd) --------------------------------- "The IMAP APPENDLIMIT Extension", Jay, Narendra Bisht, 2015-12-18, This document defines an extension to the IMAP service whereby a server can inform the client about a maximum mail upload size, allowing the client to avoid sending APPEND commands that will fail because of the messages are too large. "IMAP4 non-synchronizing literals", Alexey Melnikov, 2015-10-18, The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. The former allows the alternate form of literals in all IMAP command. The latter is the same as LITERAL+, but disallow the alternate form in IMAP APPEND, unless they are 4096 bytes or less. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Gonzalo Salgueiro, Chris Pearce, 2015-10-19, This document describes an end-to-end Session Identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. This document also describes a backwards compatibility mechanism for an existing (RFC 7329) session identifier implementation that is sufficiently different from the procedures defined in this document. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, Chidambaram Arunachalam, 2015-08-19, SIP networks use signalling 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 signalling will take between clients, and therefore impractical to monitor SIP signalling 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 signalling. 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, 2015-09-01, 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 Working Group (intarea) ------------------------------------- "IP Tunnels in the Internet Architecture", Joseph Touch, W. Townsley, 2015-07-20, This document discusses the role of IP tunnels in the Internet architecture. It explains their relationship to existing protocol layers and the challenges in supporting IP tunneling based on the equivalence of tunnels to links. "Current Hostname Practice Considered Harmful", Christian Huitema, Dave Thaler, 2015-09-09, Giving a hostname to your computer and publishing it as you roam from network to hot spot is the Internet equivalent of walking around with a name tag affixed to your lapel. The practice can significantly compromise your privacy, and should stop. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document studies another possible remedy, which is to replace the static hostnames by frequently changing randomized values. This idea obviously needs more work. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 2015-07-06, This document describes characteristics of communication between interfaces in a multi-hop ad hoc wireless network, that protocol engineers and system analysts should be aware of when designing solutions for ad hoc networks at the IP layer. "IP over Intentionally Partially Partitioned Links", Erik Nordmark, 2015-10-19, 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. "Current Hostname Practice Considered Harmful", Christian Huitema, Dave Thaler, 2015-10-13, Giving a hostname to your computer and publishing it as you roam from network to hot spot is the Internet equivalent of walking around with a name tag affixed to your lapel. The practice can significantly compromise your privacy, and should stop. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document studies another possible remedy, which is to replace the static hostnames by frequently changing randomized values. This idea obviously needs more work. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 2015-11-01, This document describes characteristics of communication between interfaces in a multi-hop ad hoc wireless network, that protocol engineers and system analysts should be aware of when designing solutions for ad hoc networks at the IP layer. IP Performance Metrics (ippm) ----------------------------- "Model Based Metrics for Bulk Transport Capacity", Matt Mathis, Al Morton, 2015-10-19, 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 key infrastructure, such as interconnects or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance. 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 but 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, 2015-10-18, 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. "A One-Way Delay Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 2015-08-20, This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete. "A One-Way Loss Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 2015-08-20, This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete. "UDP Checksum Complement in OWAMP and TWAMP", Tal Mizrahi, 2015-11-16, The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. "Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP)", Jonas Hedin, Greg Mirsky, Steve Baillargeon, 2015-11-03, This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", Nalini Elkins, Rob, Michael Ackermann, 2015-10-10, 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. "Active and Passive Metrics and Methods (and everything in-between, or Hybrid)", Al Morton, 2015-12-24, This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as Active or Passive. Some methods may use a subset of both active and passive attributes, and we refer to these as Hybrid Methods. This memo also describes multiple dimensions to help evaluate new methods as they emerge. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks", Yoav Nir, Valery Smyslov, 2015-12-16, This document recommends implementation and configuration best practices for Internet-connected IPsec Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. "Curve25519 and Curve448 for IKEv2 Key Agreement", Yoav Nir, Simon Josefsson, 2015-09-08, This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", Yoav Nir, Tero Kivinen, Paul Wouters, Daniel Migault, 2015-11-09, The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, Wenson Wu, 2015-06-16, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC5305) such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. "ISIS Auto-Configuration", Bing Liu, Bruno Decraene, Ian Farrer, Mikael Abrahamsson, Les Ginsberg, 2015-10-19, This document specifies an IS-IS auto-configuration technology. The key mechanisms of this technology are IS-IS System ID self- generation, duplication detection and duplication resolution. This technology fits the environment where plug-and-play is expected. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, Jeff Tantsura, 2015-12-14, 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. "Advertising S-BFD Discriminators in IS-IS", Les Ginsberg, Nobo Akiya, Mach Chen, 2015-03-01, This document defines a means of advertising one or more S-BFD Discriminators using the IS-IS Router Capability TLV. "IS-IS Route Preference for Extended IP and IPv6 Reachability", Les Ginsberg, Stephane Litkowski, Stefano Previdi, 2015-10-16, Existing specifications as regards route preference are not explicit when applied to IPv4/IPv6 Extended Reachability Type/Length/Value (TLVs). There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs). This document addresses these issues. This document, if approved, updates RFC 5308. "YANG Data Model for IS-IS protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Jeffrey Zhang, Ladislav Lhotka, 2015-11-18, This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. It also defined an extension module for segment routing and BFD configuration and operation. "Advertising Per-node Admin Tags in IS-IS", P. Sarkar, Hannes Gredler, Shraddha Hegde, Stephane Litkowski, Bruno Decraene, Zhenbin Li, exa, Rafael Rodriguez, Harish Raghuveer, 2015-12-08, This document describes an extension to the IS-IS routing protocol to add an optional operational capability, that allows tagging and grouping of the nodes in an IS-IS domain. This allows simple management and easy control over route and path selection, based on local configured policies. This document describes the protocol extensions to disseminate per- node administrative tags in IS-IS protocols. "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT)", Zhenbin Li, Nan Wu, Quintin <>, Alia Atlas, Chris Bowers, Jeff Tantsura, 2015-10-19, This document describes extensions to IS-IS to support the distributed computation of Maximally Redundant Trees (MRT). Example uses of MRT include IP/LDP Fast-Reroute and global protection or live-live for multicast traffic. The extensions indicate what MRT profile(s) each router supports. Different MRT profiles can be defined to support different uses and to allow transition of capabilities. An extension is introduced to flood MRT-Ineligible links, due to administrative policy. This document also defines the Controlled Convergence sub-TLV, which is useful for MRT FRR as well as other applications. "IS-IS Path Computation and Reservation", Janos Farkas, Nigel Bragg, Paul Unbehagen, Glenn Parsons, Peter Ashwood-Smith, Chris Bowers, 2015-12-17, IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. "IS-IS Prefix Attributes for Extended IP and IPv6 Reachability", Les Ginsberg, Bruno Decraene, Stefano Previdi, Xiaohu Xu, Uma Chunduri, 2015-12-17, This document introduces new sub-TLVs to support advertisement of prefix attribute flags and the source router ID of the router which originated a prefix advertisement. "Signaling Entropy Label Capability Using IS-IS", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2015-11-10, 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 that it can process ELs for 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, 2015-11-29, This document specifies an IS-IS auto-configuration technology. The key mechanisms of this technology are IS-IS System ID self- generation, duplication detection and duplication resolution. This technology fits the environment where plug-and-play is expected. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JWS Unencoded Payload Option", Michael Jones, 2015-12-23, JSON Web Signature (JWS) represents the payload of a JWS as a base64url encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit. This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification. Javascript Object Notation Update (jsonbis) ------------------------------------------- "The JavaScript Object Notation (JSON) Data Interchange Format", Tim Bray, 2015-10-19, JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 2015-10-10, Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. "AES Encryption with HMAC-SHA2 for Kerberos 5", Michael Jenkins, Michael Peck, Kelley Burgin, 2015-12-09, This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", Shawn Emery, Nicolas Williams, 2015-12-11, This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. "Kerberos Authorization Data Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, 2015-11-01, This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension", Michiko Short, Seth Moore, Paul Miller, 2015-12-11, This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer Schatzmayr, Wim Henderickx, 2015-07-06, This document describes a simple L2 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. "Advertising S-BFD Discriminators in L2TPv3", Vengada Govindan, Carlos Pignataro, 2015-11-18, This document defines a new AVP for advertising one or more S-BFD Discriminators using the L2TPv3 Control Protocol AVP. "A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing Liu, Giles Heron, 2015-07-25, This document defines a YANG data model for the configuration and management of Keyed IPv6 tunnels. The data model includes configuration data and state data. Due to the stateless nature of keyed IPv6 tunnels, a model for NETCONF notifications is not necessary. L3VPN Service Model (l3sm) --------------------------- "YANG Data Model for L3VPN service delivery", Stephane Litkowski, Rob Shakir, Luis Tomotaki, Kevin D'Souza, 2015-12-15, This document defines a YANG data model that can be used to deliver a Layer 3 Provider Provisioned VPN service. The document is limited to the BGP PE-based VPNs as described in RFC4110 and RFC4364. 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. This model provides an abstracted view of the Layer 3 IPVPN service configuration components. It will be 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. Label Generation Rules (lager) ------------------------------ "Representing Label Generation Rulesets using XML", Kim Davies, Asmus Freytag, 2015-12-11, This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and specific Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- "Generic YANG Data Model for Operations, Administration, and Maintenance (OAM)", Tissa Senevirathne, Norman Finn, Deepak Kumar, Samer Salam, Qin Wu, Zitao Wang, 2015-11-27, This document presents base YANG Data model for OAM. It provides a protocol-independent and technology-independent abstraction of key OAM constructs. Based model presented here can be extended to include technology specific details. This is leading to uniformity between OAM technologies and support nested OAM workflows (i.e., performing OAM functions at different layers through a unified interface). Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP EID Block", Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller, 2015-05-19, This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2015-10-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 Threats Analysis", Damien Saucez, Luigi Iannone, Olivier Bonaventure, 2015-12-20, This document provides a threat analysis of the Locator/Identifier Separation Protocol (LISP). "LISP Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job Snijders, 2015-09-18, This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. "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 EID Block Management Guidelines", Luigi Iannone, Roger Jorgensen, David Conrad, Geoff Huston, 2015-08-24, This document proposes a framework for the management of the LISP EID Prefix. The framework described relies on hierarchical distribution of the address space, granting temporary usage of sub-prefixes of such space to requesting organizations. "LISP Impact", Damien Saucez, Luigi Iannone, Albert Cabellos-Aparicio, Florin Coras, 2015-11-20, The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet routing scalability properties by leveraging on three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end-user. "LISP Data-Plane Confidentiality", Dino Farinacci, Brian Weis, 2015-12-04, This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. "LISP Configuration YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Albert Cabellos-Aparicio, Fabio Maino, 2015-12-17, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2015-12-21, 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. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- "Information Model for Large-Scale Measurement Platforms (LMAP)", Trevor Burbridge, Philip Eardley, Marcelo Bagnulo, Jürgen Schönwälder, 2015-11-01, 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 MA 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 MA that can be implemented via one or more Control and Report protocols. "A YANG Data Model for LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-11-01, This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. "Using RESTCONF with LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-11-01, This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Minimal IKEv2 Initiator Implementation", Tero Kivinen, 2015-11-23, This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as responder, thus two minimal initiator implementations cannot talk to each other. This document does not update or modify RFC 7296, but provides more compact description of the minimal version of the protocol. If this document and RFC 7296 conflicts then RFC 7296 is the authoritative description. "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keranen, 2015-08-27, 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. "CoAP Implementation Guidance", Matthias Kovatsch, Olaf Bergmann, Carsten Bormann, 2015-07-06, 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. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Bo Berry, Shawn Jury, Darryl Satterwhite, Rick Taylor, 2015-10-16, 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. A bidirectional, event- driven communication channel between the router and the modem is necessary. "Ad Hoc On-demand Distance Vector Routing Version 2 (AODVv2)", Charles Perkins, Stan Ratliff, John Dowdell, Lotte Steenbrink, Victoria Mercieca, 2015-10-13, The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. "Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Christopher Dearlove, Thomas Clausen, 2015-09-28, This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions. "Packet Sequence Number based directional airtime metric for OLSRv2", Henning Rogge, Emmanuel Baccelli, 2015-12-15, This document specifies an Directional Airtime (DAT) link metric for usage in OLSRv2. "Identity-Based Signatures for MANET Routing Protocols", Christopher Dearlove, 2015-11-30, This document extends RFC7182, which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in RFC5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in RFC6507. "Definition of Managed Objects for the Neighborhood Discovery Protocol", Ulrich Herberg, Robert Cole, Ian Chakeres, Thomas Clausen, 2015-03-03, This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. "Security Threats for Simplified Multicast Forwarding (SMF)", Jiazi Yi, Thomas Clausen, Ulrich Herberg, 2015-11-06, This document analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. "Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Jiazi Yi, Benoit Parrein, 2015-07-21, 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 for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Thomas Clausen, Ulrich Herberg, Jiazi Yi, 2015-11-06, This document analyzes common security threats of 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, 2015-12-22, This document updates the generalized MANET packet/message format, specified in RFC 5444, by providing rules and recommendations for how protocols can use that 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 generic RFC 5444 parsers. "Credit Windowing extension for DLEP", Stan Ratliff, 2015-10-16, Extends the DLEP protocol to provide a credit-windowing scheme analogous to that in RFC5578 for destination-specific flow control. MBONE Deployment (mboned) ------------------------- "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Kerry Meyer, Weesan Lee, 2015-10-09, 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. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed Boucadair, Stig Venaas, Qiong, 2015-12-09, Each IPTV operator has their own arrangements for pre-provisioning program information including addresses of the multicast groups corresponding to broadcast programs on the subscriber receiver. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines what has to be done to allow the receiver to acquire multicast address information in the version it supports in such scenarios. "Use of Multicast Across Inter-Domain Peering Points", Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, Ram (Ramki) Krishnan, 2015-07-20, This document examines the use of multicast across inter-domain peering points. The objective is to describe the setup process for multicast-based delivery across administrative domains and document supporting functionality to enable this process. Multiple Interfaces (mif) ------------------------- "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 2015-12-20, This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 and fit into a multiple provisioning domain architecture. Happy Eyeballs in MIF would make the selection process smoother by using connectivity tests over pre-filtered interfaces according to defined policy. This would choose the most fast interface with an automatic fallback mechnism. "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", Jouni Korhonen, Suresh Krishnan, Sri Gundavelli, 2015-10-19, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. One part of the solution requires associating configuration information with provisioning domains. This document details how configuration information provided through IPv6 Neighbor Discovery Protocol can be associated with provisioning domains. "Support for multiple provisioning domains in DHCPv6", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, 2015-10-19, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. One part of the solution requires associating configuration information with provisioning domains. This document details how configuration information provided through DHCPv6 can be associated with provisioning domains. "Identification of provisioning domains", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, Sri Gundavelli, 2015-10-19, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "IODEF Usage Guidance", Mio Suzuki, Panos Kampanakis, 2015-10-19, The Incident Object Description Exchange Format [RFC5070] 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 implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF and use-cases of how IODEF is being used so far.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. "The Incident Object Description Exchange Format v2", Roman Danyliw, Paul Stoecker, 2015-10-16, The Incident Object Description Exchange Format (IODEF) defines a data representation for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. "MILE Implementation Report", Christopher Inacio, daisu-mi@nc.u-tokyo.ac.jp, 2015-10-18, 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 Indicator Exchange", John Field, 2015-12-02, This document defines a resource-oriented approach to cyber security information sharing. Using this approach, a CSIRT or other stakeholder may share and exchange representations of cyber security incidents, indicators, and other related information as Web- addressable resources. The transport protocol binding is specified as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of link relation types specific to cyber security information sharing is defined. The resource representations leverage the existing IODEF [RFC5070] and RID [RFC6545] specifications as appropriate. Coexistence with deployments that conform to existing specifications including RID [RFC6545] and Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via appropriate use of HTTP status codes. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 2014-02-10, This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-layer protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund, Thomas Zeng, 2014-07-10, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams set up and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 2015-11-03, 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. "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Christer Holmberg, Salvatore Loreto, Gonzalo Camarillo, 2015-09-07, The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2015-07-20, 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, associated with 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. 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, 2015-10-01, 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, 2015-10-19, 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, 2015-07-05, The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. Typically media associated with individual media descriptions ("m=" lines) represent RTP sessions and are thus carried over individual underlying transport layer flows. For scenarios where SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions, it is required to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. 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, Enrico Marocco, Christer Holmberg, 2015-10-02, 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, 2015-10-19, 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 discusses the best way of accomplishing simulcast in RTP and how to signal it in SDP. A solution is defined by making an extension to SDP, and using RTP/RTCP identification methods to relate RTP streams belonging to the same media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. RTP/RTCP identification using either payload types or a separately defined method for RTP stream configuration are defined. "SDP-based Data Channel Negotiation", Keith Drage, Raju Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-11-30, 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, Raju Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-11-03, 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). "IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.", Suhas Nandakumar, 2015-10-08, RTP provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The RTP specification [RFC3550] establishes a registry of profile names for use by higher-level control protocols, such as the SDP, to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. "Using the SDP Offer/Answer Mechanism for DTLS", Christer Holmberg, Roman Shpount, 2015-12-08, This draft defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The draft also defines the criteria for when a new DTLS association must be established. This draft defines a new SDP media-level attribute, 'dtls- connection'. "RTP Payload Format Constraints", Peter Thatcher, Mo Zanaty, Suhas Nandakumar, Bo Burman, Adam Roach, Byron Campen, 2015-11-11, In this specification, we define a framework for identifying Source RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework uses "rid" SDP attribute to: a) effectively identify the Source RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the Source RTP Streams to their media format specification in the SDP. Note-1: The name 'rid' is not yet finalized. Please refer to Section 12 for more details on the naming. Multiprotocol Label Switching (mpls) ------------------------------------ "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping", Elisa Bellagamba, Greg Mirsky, Loa Andersson, Pontus Skoldstrom, David Ward, John Drake, 2015-11-23, This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP-Ping protocol. "Enhanced path segment monitoring", Alessandro D'Alessandro, Loa Andersson, Manuel Paul, Satoshi Ueno, Kaoru Arai, Yoshinori Koike, 2015-12-18, The MPLS transport profile (MPLS-TP) has been standardized to enable carrier-grade packet transport and to complement converged packet network deployments. The most attractive features of MPLS-TP are the OAM functions. These functions enable maintenance tools that may be exploited by network operators and service providers for fault location, survivability, performance monitoring, in-service and out- of-service measurements. One of the most important mechanisms that is common for transport network operation is fault localisation. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable, particularly when the OAM function is activated only between end points. However, the current approach defined for MPLS-TP of segment monitoring has some drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provide monitoring of a segment of a set of transport paths (LSPs or MS-PWs). Based on the identified problems, this document provides considerations for the specification of new requirements to consider a new improved mechanism for hitless transport path segment monitoring to be named Enhanced Path Segment Monitoring (EPSM). "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2015-09-10, 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 the Operations, Administration, and Management (OAM) identifiers for Multiprotocol Label Switching (MPLS) and MPLS-based Transport Profile (TP). "MPLS Transport Profile Linear Protection MIB", Kingston Smiler, Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin, Jeong-dong Ryoo, 2015-12-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. "Relayed Echo Reply mechanism for LSP Ping", Luo Jian, Lizhong Jin, Tom Nadeau, George Swallow, 2015-10-05, In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. "mLDP Node Protection", IJsbrand Wijnands, Kamran Raza, Alia Atlas, Jeff Tantsura, Quintin Zhao, 2015-09-29, This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) that have been built by the "Multipoint Label Distribution Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point of Local Repair (PLR) Label Switched Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. "Use Cases and Requirements for MPLS-TP multi-failure protection", Zhenlong Cui, Rolf Winter, Himanshu Shah, Sam Aldrin, Masahiro Daikoku, 2015-07-06, 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. "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, 2015-07-30, 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. "Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula, Uwe Joorde, Arvind Venkateswaran, 2015-10-12, 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. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, George Swallow, 2015-09-08, 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, which is a key goal of the MPLS Fabric architecture. "RFC6374 UDP Return Path", Stewart Bryant, Siva Sivabalan, Sagar Soni, 2015-08-26, This document specifies the procedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. "Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification", Nobo Akiya, George Swallow, Carlos Pignataro, Loa Andersson, Mach Chen, 2015-10-09, The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode, the value of this Reply Mode is 5. The update creates a simple way to indicate that the Reverse LSP should be used as return path. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC7110. "Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces", Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, 2015-07-24, This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 4379. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC4379 and RFC6424. "LDP Extensions to Support Maximally Redundant Trees", Alia Atlas, Kishore Tiruveedhula, Chris Bowers, Jeff Tantsura, IJsbrand Wijnands, 2015-09-30, 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 and LERs 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, Chris Bowers, Luay Jalil, Uma Chunduri, Zhenbin Li, Kamran Raza, 2015-08-20, Recent targeted LDP 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 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. "Entropy labels for source routed stacked tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, rjs@rob.sh, Xiaohu Xu, Wim Henderickx, Jeff Tantsura, 2015-09-07, Source routed tunnel stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed stacked tunnels. "Handling the TC and TTL fields in a Label Stack Entry that Contains the Generic Associated Channel Label", Sasha, Loa Andersson, Adrian Farrel, 2015-09-24, This document clarifies handling of the Traffic Class (TC) and Time- to-Live (TTL) fields of a Label Stack Entry that contains the Generic Associated Channel (G-ACh) Label (GAL). These clarifications are intended to aid interoperability of implementations. Original handling was defined in RFC 5586, and this document updates that RFC. "LSP Self-Ping", Ron Bonica, Ina Minei, Michael Conn, Dante Pacella, Luis Tomotaki, 2015-11-01, When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. "Opportunistic Security in MPLS Networks", Adrian Farrel, Stephen Farrell, 2015-07-23, 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", Greg Mirsky, Stefano Ruffini, Eric Gray, John Drake, Stewart Bryant, Sasha, 2015-08-04, This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and 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 PTP event message. "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", Kireeti Kompella, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Mach Chen, 2015-12-18, 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 RFC 4379. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2015-09-08, Bidirectional Forwarding Detection (BFD) is expected to monitor bi- directional paths. When a BFD session monitors in its forward direction an explicitly routed path there is a need to be able to direct egress BFD peer to use specific path as reverse direction of the BFD session. "MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology", Weiqiang Cheng, Lei Wang, Han Li, Huub van Helvoort, Kai Liu, Jie Dong, He Jia, Fang Li, Yang Jian, Junfang Wang, 2015-10-09, This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point- to-point (P2P) services. The mechanism of MSRP is illustrated and how it satisfies the requirements for optimized ring protection in RFC 5654 is analyzed. This document also defines the Ring Protection Switch (RPS) Protocol which is used to coordinate the protection behavior of the nodes on MPLS ring. "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2015-11-01, 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, Greg Mirsky, 2015-12-18, This memo discusses the desired capabilities for MPLS flow identification. The key application that needs this is in-band performance monitoring of user data packets. Multipath TCP (mptcp) --------------------- "Use Cases and Operational Experience with Multipath TCP", Olivier Bonaventure, Christoph Paasch, Gregory Detal, 2015-10-19, This document discusses both use cases and operational experience with Multipath TCP in real world networks. It lists several prominent use cases for which Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases. Network Configuration (netconf) ------------------------------- "RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-12-15, This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. "YANG Patch Media Type", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-12-15, This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. "NETCONF Server and RESTCONF Server Configuration Models", Kent Watsen, Jürgen Schönwälder, 2015-10-09, This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listen on, call-home parameters, client authentication, and related parameters. "Zero Touch Provisioning for NETCONF Call Home", Kent Watsen, Joe Clarke, 2015-10-19, This draft presents a technique for establishing a secure NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its rightful owner's network management system (NMS). "NETCONF Call Home and RESTCONF Call Home", Kent Watsen, 2015-12-22, This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. "YANG Module Library", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-12-15, This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information. "Subscribing to YANG datastore push updates", Alex Clemm, Alberto Prieto, Eric Voit, 2015-10-15, This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to the client per a subscription policy, without requiring additional client requests. Network-Based Mobility Extensions (netext) ------------------------------------------ "Logical-interface Support for Multi-access enabled IP Hosts", Telemaco Melia, Sri Gundavelli, 2015-11-13, A Logical-interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical-interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 2015-12-23, Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. NETCONF Data Modeling Language (netmod) --------------------------------------- "A YANG Data Model for Routing Management", Ladislav Lhotka, Acee Lindem, 2015-10-16, This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), and routing protocols. "JSON Encoding of Data Modeled with YANG", Ladislav Lhotka, 2015-10-07, This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2015-10-19, 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) implementations that utilize YANG data model modules. "The YANG 1.1 Data Modeling Language", Martin Bjorklund, 2015-12-11, YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols like the Network Configuration Protocol (NETCONF). "SYSLOG YANG model", Clyde Wildes, 2015-12-22, This document describes a data model for Syslog protocol which is used to convey event notification messages. "Network Access Control List (ACL) YANG Data Model", Dean Bogdanovic, Kiran Koushik, Lisa Huang, Dana Blair, 2015-12-09, This document describes a data model of Access Control List (ACL) basic building blocks. "Defining and Using Metadata with YANG", Ladislav Lhotka, 2015-09-17, This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. "NETMOD Operational State Requirements", Kent Watsen, Tom Nadeau, 2015-12-15, This document defines requirements for servers enabling better visibility and control over the server's operational state. To achieve this end, this document also defines terminology describing a conceptual model enabling the requirements to be expressed. "YANG Model Classification", Dean Bogdanovic, Benoit Claise, Carl Moberg, 2015-12-07, The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards defining organizations, open source software projects, and vendors are using YANG to develop and publish models of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG models. A consistent terminology would help with the categorization of models, assist in the analysis 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 models. Internet Video Codec (netvc) ---------------------------- "