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 2016-09-17 00:05:26 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel, 2016-05-16, 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, 2016-06-16, 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", Yong-Geun Hong, Joo-Sang Youn, 2016-07-08, Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques. "Privacy Considerations for IPv6 over Networks of Resource-Constrained Nodes", Dave Thaler, 2016-09-13, 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 adaptation layer specifications for IPv6 over such links. "An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX)", Yoshihiro Ohba, 2016-04-19, 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. "IPv6 Backbone Router", Pascal Thubert, 2016-03-18, This specification proposes an update to IPv6 Neighbor Discovery, to enhance the operation of IPv6 over wireless links that exhibit lossy multicast support, and enable a large degree of scalability by splitting the broadcast domains. A higher speed backbone federates multiple wireless links to form a large MultiLink Subnet. Backbone Routers acting as Layer-3 Access Point route packets to registered nodes, where an classical Layer-2 Access Point would bridge. Conversely, wireless nodes register to the Backbone Router to setup routing services in a fashion that is essentially similar to a classical Layer-2 association. "6LoWPAN Paging Dispatch", Pascal Thubert, Robert Cragie, 2016-09-09, This specification updates RFC 4944 to introduce a new context switch mechanism for 6LoWPAN compression, expressed in terms of Pages and signaled by a new Paging Dispatch. "6lowpan ESC Dispatch Code Points and Guidelines", Samita Chakrabarti, Gabriel Montenegro, Ralph Droms, james woodyatt, 2016-09-16, RFC4944 defines the ESC dispatch type to allow for additional dispatch bytes in the 6lowpan header. The value of the ESC byte was updated by RFC6282, however, its usage was not defined either in RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by defining the ESC extension byte code points including registration of entries for known use cases at the time of writing of this document. "Assignment of an Ethertype for IPv6 with LoWPAN Encapsulation", Ralph Droms, Paul Duffy, 2016-06-06, When carried over layer 2 technologies such as Ethernet, IPv6 datagrams using LoWPAN encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. This document requests the assignment of an Ethertype for that purpose. IPv6 Maintenance (6man) ----------------------- "Recommendation on Stable IPv6 Interface Identifiers", Fernando Gont, Alissa Cooper, Dave Thaler, Shucheng LIU, 2016-08-20, This document changes the recommended default IID generation scheme for cases where SLAAC is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. "Generation of IPv6 Atomic Fragments Considered Harmful", Fernando Gont, Shucheng LIU, Tore Anderson, 2016-09-12, This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments, and concludes that the aforementioned functionality is undesirable, thus documenting the motivation for removing this functionality in the revision of the core IPv6 protocol specification. "IPv6 Neighbor Discovery Optional RS/RA Refresh", Erik Nordmark, Andrew Yourtchenko, Suresh Krishnan, 2016-03-21, IPv6 Neighbor Discovery relies on periodic multicast Router Advertisement messages to update timer values and to distribute new information (such as new prefixes) to hosts. On some links the use of periodic multicast messages to all host becomes expensive, and in some cases it results in hosts waking up frequently. Many implementations of RFC 4861 also use multicast for solicited Router Advertisement messages, even though that behavior is optional. This specification provides an optional mechanism for hosts and routers where instead of periodic multicast Router Advertisements the hosts are instructed (by the routers) to use Router Solicitations to request refreshed Router Advertisements. This mechanism is enabled by configuring the router to include a new option in the Router Advertisement in order to allow the network administrator to choose host behavior based on whether periodic multicast are more efficient on their link or not. The routers can also tell whether the hosts are capable of the new behavior through a new flag in the Router Solicitations. "IPv6 Router Advertisement Options for DNS Configuration", Jaehoon Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli, 2016-06-14, This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document obsoletes RFC 6106 and allows a higher default value of the lifetime of the DNS RA 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, 2016-02-18, 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. "First-hop router selection by hosts in a multi-prefix network", Jerome Marcon, Brian Carpenter, 2016-08-24, This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement 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. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. 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", Robert Hinden, 2016-09-13, This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 "IPv6 Hop-by-Hop Options Extension Header", Fred Baker, Ron Bonica, 2016-03-16, This document clarifies requirements for IPv6 routers with respect to the Hop-by-Hop (HBH) Options Extension Header. These requirements are applicable to all IPv6 routers, regardless of whether they maintain a strict separation between forwarding and control plane hardware. In this respect, this document updates RFC 2460 and RFC 7045. This document also describes forwarding plane procedures for processing the HBH Options Extension Header. These procedures are applicable to implementations that maintain a strict separation between forwarding and control plane implementations. The procedures described herein satisfy the above mentioned requirements by processing HBH Options on the forwarding plane to the greatest degree possible. If a packet containing HBH Options must be dispatched to the control plane, it is rate limited before dispatching. In order to comply with the requirements of this specification, implementations may execute the procedures described herein or any other procedures that result in compliant behavior. "Support for adjustable maximum router lifetimes per-link", Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko, 2016-07-08, 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, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 2016-03-18, Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. "IP Version 6 Addressing Architecture", Robert Hinden, Steve Deering, 2016-09-13, This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". "Path MTU Discovery for IP version 6", Jack <>, Stephen <>, Jeffrey <>, Robert Hinden, 2016-04-27, This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Pascal Thubert, 2016-06-10, This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications. "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2016-03-21, 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, 2016-06-28, This document describes a minimal mode of operation for a 6TiSCH Network, to provide IPv6 connectivity over a Non-Broadcast Multi- Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links. This minimal mode uses a collection of protocols including the 6LoWPAN framework to enable interoperable IPv6 connectivity over IEEE 802.15.4 TSCH with minimal network configuration and infrastructure. "6top Protocol (6P)", Qin Wang, Xavier Vilajosana, 2016-07-25, This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes in a 6TiSCH network to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. Different SFs are expected to be defined in future companion specifications. "6TiSCH 6top Scheduling Function Zero (SF0)", Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura, 2016-07-08, This document defines a 6top Scheduling Function called "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of reserved cells between neighbor nodes, based on the currently allocated bandwidth and the neighbour nodes' requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the cell(s) to be added/deleted. SF0 uses the 6P signaling messages to add/delete cells in the schedule. Some basic rules for deciding when to add/ delete cells and for selecting the cells to be added/deleted within the schedule are also provided. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations", Rhys Smith, Mark Donnelly, 2016-03-21, 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) ------------------------------------------------------------------- "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Göran Selander, Carsten Bormann, 2016-09-03, Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. "Authentication and Authorization for Constrained Environments (ACE)", Ludwig Seitz, Göran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2016-06-10, This specification defines the ACE framework for authentication and authorization in Internet of Things (IoT) deployments. The ACE framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the limitations of IoT devices require it, profiles and extensions are provided. "CBOR Web Token (CWT)", Erik Wahlstroem, Michael Jones, Hannes Tschofenig, Samuel Erdtman, 2016-07-07, CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/ value pair consisting of a claim name and a claim value. Automated Certificate Management Environment (acme) --------------------------------------------------- "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, James Kasten, 2016-07-08, 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, Michael Scharf, Hans Seidel, Stefano Previdi, 2016-07-20, Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates, which are able to provide a desired resource. This memo discusses deployment related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and CDNs and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such recommendations how to generate ALTO map information. "Multi-Cost ALTO", Sabine Randriamasy, Wendy Roome, Nico Schwan, 2016-09-15, The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. An ALTO Server may offer a variety of cost metrics, based on latency,bandwidth, hop count, jitter, or whatever else the ALTO Server deems useful. For example, when downloading a file that is mirrored on several sites, a user application may consider more than one metric, perhaps trading bandwidth for latency to determine the most efficient mirror site. While the base ALTO Protocol allows an ALTO Client to use more than one cost metric, to do so, the Client must request each metric separately. This document defines a new service that allows a Client to retrieve several cost metrics with one request, which is considerably more efficient. In addition, this document extends the ALTO constraint tests to allow a user to specify an arbitrary logical combination of tests on several cost metrics. "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2016-09-13, The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information to client applications so that clients may make informed decisions. To that end, an ALTO Server provides Network and Cost Maps. Using those maps, an ALTO Client can determine the costs between endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to those maps, other than by periodically re-fetching them. Because the maps may be large (potentially tens of megabytes), and because only parts of the maps may change frequently (especially Cost Maps), that can be extremely inefficient. Therefore this document presents a mechanism to allow an ALTO Server to provide updates to ALTO Clients. Updates can be both immediate, in that the server can send updates as soon as they are available, and incremental, in that if only a small section of a map changes, the server can send just the changes. "ALTO Cost Calendar", Sabine Randriamasy, Yang Yang, Wenson Wu, Deng Lingli, Nico Schwan, 2016-08-15, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information in order to allow applications to make network informed decisions. The present draft extends the ALTO cost information so as to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that need to schedule their data transfers and connections and have a degree of freedom to do so. ALTO guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. Besides, the ALTO Cost Calendar allows to schedule the ALTO requests themselves and thus to save a number of ALTO transactions. This draft proposes new capabilities and attributes on filtered cost maps and endpoint costs enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to time-sensitive ALTO metrics. With ALTO Cost Calendars, an ALTO Server exposes ALTO Cost Values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes are specified in the IRD and ALTO Server responses. "ALTO Performance Cost Metrics", Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2016-09-07, Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Future extensions to ALTO may also use Cost Metric. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that have low delay to the Resource Consumer. However the base ALTO protocol [ALTO] has documented only a single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). In this document, we proposes a set of Cost Metrics, derived and aggregated from routing protocols with different granularity and scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end to end traffic management tool. We currently document 11 new Performance Metric to measure network delay, jitter, packet loss, hop count, and bandwidth. The metrics documented in this document provide a relatively comprehensive set of Cost Metrics for ALTO and allow applications to determine "where" to connect based on end to end network performance criteria. Additional Cost Metrics such as financial cost metrics may be documented in other documents. Autonomic Networking Integrated Model and Approach (anima) ---------------------------------------------------------- "A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian Carpenter, Bing Liu, 2016-09-12, 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, Toerless Eckert, Steinthor Bjarnason, 2016-07-08, Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, 2016-06-30, This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) 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 redirected to a local service. In limited/ disconnected networks or legacy environments we describe a variety of options that allow bootstrapping to proceed. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. "A Reference Model for Autonomic Networking", Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Peloso Pierre, Bing Liu, Jéferson Nobre, John Strassner, 2016-07-08, This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun, 2016-07-08, This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. "Using Autonomic Control Plane for Stable Connectivity of Network OAM", Toerless Eckert, Michael Behringer, 2016-07-08, OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN). to provide stable and secure connectivity for those OAM processes. ART Area General Applications Working Group (appsawg) ----------------------------------------------------- "Message Disposition Notification", Tony Hansen, Alexey Melnikov, 2016-08-12, 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. This document obsoletes RFC 3798 and updates RFC 2046 and RFC 3461. "The file URI Scheme", Matthew Kerwin, 2016-08-14, This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . Active Queue Management and Packet Scheduling (aqm) --------------------------------------------------- "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, Janardhan Iyengar, 2016-06-02, 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, Greg White, 2016-08-02, Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. 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 latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, 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 timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software. "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", Toke Hoeiland-Joergensen, Paul McKenney, dave.taht@gmail.com, Jim Gettys, Eric Dumazet, 2016-03-18, This memo presents the FQ-CoDel hybrid packet scheduler/Active Queue Management algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. "A PIE-Based AQM for DOCSIS Cable Modems", Greg White, Rong Pan, 2016-02-15, 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) ------------------------------------- "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, Victor Pascual, Gonzalo Salgueiro, Ram R, 2016-08-15, The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP are not available (for example, from within Javascript in a web browser). This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", Christoph Vigano, Henk Birkholz, 2016-03-21, This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR. "Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9", Sean Leonard, 2016-07-19, PKCS #9 includes several useful definitions that are not yet reflected in the LDAP IANA registry. This document adds those definitions to the IANA registry. "Internet Printing Protocol/1.1: Encoding and Transport", Michael Sweet, Ira McDonald, 2016-08-23, The Internet Printing Protocol (IPP) is an application level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in IPP/1.1: Model and Semantics [RFC2911bis]. This document obsoletes RFCs 2910 and 3382. "Internet Printing Protocol/1.1: Model and Semantics", Michael Sweet, Ira McDonald, 2016-08-25, The Internet Printing Protocol (IPP) is an application level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects including Printers and Jobs. Jobs optionally support multiple Documents. IPP semantics allow End Users and Operators to query Printer capabilities, submit print Jobs, inquire about the status of print Jobs and Printers, and cancel, hold, and release print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers. Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in IPP/1.1: Encoding and Transport [RFC2910bis]. This document obsoletes RFCs 2911, 3381, and 3382. "DAV Server Information Object", Michael Douglass, 2016-04-17, This specification describes a new XML object that can be retrieved from hosts to discover applications, features and limits for that host or domain. "E-mail Authentication for Internationalized Mail", John Levine, 2016-07-03, SPF, DKIM, and DMARC enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. This specification clarifies when to use which form of domain names when using SPF, DKIM, and DMARC. "IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service", Christer Holmberg, Jörgen Axell, 2016-08-12, This document creates an additional Session Initiation Protocol (SIP) Resource-Priority namespace to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places this namespace in the IANA registry. "Regular Expressions for Internet Mail", Sean Leonard, 2016-03-21, Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms. "Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan Bosch, 2016-04-04, The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned. "Advertising Digital Identification (Ad-ID) URN Namespace Definition", jwold@ad-id.org, 2016-04-14, Advertising Digital Identification (Ad-ID) Identifiers are used identifying Advertising Assets across all media platforms (over the air, on-line, over the top, mobile, place based). This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for Ad-ID Identifiers. "Signalling one-click functionality for list email headers", John Levine, Tobias Herkula, 2016-09-15, This document describes a method for signaling a one-click function for the list-unsubscribe email header. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail headers, and thereby accidentally triggers unsubscriptions in the case of the list-unsubscribe header. "Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)", Julien Elie, 2016-08-05, This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. If approved, this document updates RFC 4642. 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, 2016-08-18, 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 these applications, then network congestion can lead to uncontrolled packet loss, and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure, stopping RTP flows from using excessive resources, and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data, to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. "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, 2016-03-02, RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. "Multipath RTP (MPRTP)", Varun Singh, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 2016-07-08, 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, 2016-09-01, This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document. This document updates RFC 5764. "A General Mechanism for RTP Header Extensions", Roni Even, David Singer, HariKishan Desineni, 2016-08-14, 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. "Updates to RFC 5761", Christer Holmberg, 2016-09-15, This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTCP multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in an SDP answer if the associated SDP offer contained the attribute. Audio/Video Transport Extensions (avtext) ----------------------------------------- "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli, 2016-08-03, Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. "The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2016-07-08, This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. "Frame Marking RTP Header Extension", Espen Berger, Suhas Nandakumar, Mo Zanaty, 2016-07-18, 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. "RTP Stream Identifier Source Description (SDES)", Adam Roach, Suhas Nandakumar, Peter Thatcher, 2016-08-26, This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", Stephan Wenger, Jonathan Lennox, Bo Burman, Magnus Westerlund, 2016-05-17, This document fixes a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) as defined in RFC5104 when using with layered codecs. In particular, a Decoder Refresh Point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found. Babel routing protocol (babel) ------------------------------ "Applicability of the Babel routing protocol", Juliusz Chroboczek, 2016-07-08, This document describes some application areas where the Babel routing protocol [RFC6126] has been found to be useful. "The Babel Routing Protocol", Juliusz Chroboczek, 2016-08-01, Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. BGP Enabled ServiceS (bess) --------------------------- "AC-Influenced Designated Forwarder Election for EVPN", Jorge Rabadan, Kiran Nagaraj, Senthil Sathappan, Vinod Prabhu, Wim Henderickx, Autumn Liu, Wen Lin, 2016-08-02, The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. While PE node or link failures trigger the DF re-election for a given , individual Attachment Circuit (AC) or MAC-VRF failures do not trigger such DF re-election and the traffic may therefore be permanently impacted, even though there is an alternative path. This document improves the DF election algorithm so that the AC status can influence the result of the election and this type of "logical" failures can be protected too. "L2L3 VPN Multicast MIB", Zhaohui Zhang, 2016-05-18, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes common managed objects used to configure and/or monitor both L2 and L3 VPN Multicast. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Keyur Patel, Ali Sajassi, Aldrin Isaac, 2016-03-19, This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. "A Network Virtualization Overlay Solution using EVPN", Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx, 2016-06-09, 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. "Ingress Replication Tunnels in Multicast VPN", Eric Rosen, Karthik Subramanian, Zhaohui Zhang, 2016-08-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. "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Ali Sajassi, Dennis Cai, 2016-09-08, 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, 2016-08-03, 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, John Drake, Wen Lin, Ali Sajassi, 2016-09-13, 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, jefftant@gmail.com, Dirk Steinberg, Thomas Beckhaus, Jorge Rabadan, 2016-07-05, This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. "E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, John Drake, Jim Uttaro, Sami Boutros, Jorge Rabadan, 2016-09-01, The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in and RFC called "A Framework for E-Tree Service over MPLS Network". This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates that RFC accordingly. "VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, Samir Thoria, tsingh@juniper.net, John Drake, Jeff Tantsura, 2016-03-16, This document describes how Ethernet VPN (E-VPN) technology can be used to interconnect VXLAN or NVGRE networks over an MPLS/IP network. This is to provide intra-subnet connectivity at Layer 2 and control- plane separation among the interconnected VXLAN or NVGRE networks. The scope of the learning of host MAC addresses in VXLAN or NVGRE network is limited to data plane learning in this document. "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, 2016-04-21, This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2016-05-25, [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]. "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler, 2016-07-07, This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertized toward a standby upstream PE. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2016-07-08, This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. "Operational Aspects of Proxy-ARP/ND in EVPN Networks", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, Erik Nordmark, 2016-04-04, The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast- forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in [RFC6820]. This document describes how the [RFC7432] EVPN proxy- ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. "A new Designated Forwarder Election for the EVPN", satyamoh@cisco.com, Keyur Patel, Ali Sajassi, John Drake, Tony Przygienda, 2016-04-06, This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN "Service Chaining using Virtual Networks with BGP VPNs", Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin, 2016-04-14, This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. "Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang, 2016-06-20, The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFC6625. "Yang Data Model for EVPN", Patrice Brissette, Ali Sajassi, Himanshu Shah, Zhenbin Li, Kishore Tiruveedhula, Iftekhar Hussain, Jorge Rabadan, 2016-07-08, This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. Any "add-on" features such as EVPN IRB, EVPN overlay, etc. are for future investigation. This document mainly focuses on EVPN and Ethernet-Segment instance framework. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, I. Chen, Iftekhar Hussain, Bin Wen, 2016-06-26, This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. "Yang Data Model for BGP/MPLS L3 VPNs", Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen, 2016-09-13, This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 2015-11-13, Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Gonzalo Camarillo, Tom Kristensen, Paul Jones, 2016-07-06, 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, 2016-06-14, 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. "Session Description Protocol (SDP) WebSocket Connection URI Attribute", Ram R, Gonzalo Salgueiro, 2016-07-20, The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, 2016-04-18, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. "BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks, 2016-05-23, 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, Gregory Mirsky, 2016-07-08, This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). Bit Indexed Explicit Replication (bier) --------------------------------------- "Multicast using Bit Index Explicit Replication", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Tony Przygienda, Sam Aldrin, 2016-07-18, This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification. "OSPF Extensions for BIER", Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Zhaohui Zhang, Sam Aldrin, 2016-09-14, Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the OSPF protocol extension required for BIER with MPLS encapsulation. "Encapsulation for Bit Index Explicit Replication in MPLS Networks", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam Aldrin, Israel Meilik, 2016-07-08, 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, Sam Aldrin, Andrew Dolganow, Tony Przygienda, 2016-07-18, 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 draft-ietf-bier-use-cases-03 .txt", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, arkadiy.gulko@thomsonreuters.com, Dom Robinson, Vishal Arya, Caitlin Bestler, 2016-07-07, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes some of the use-cases for BIER. "BIER support via ISIS", Les Ginsberg, Tony Przygienda, Sam Aldrin, Zhaohui Zhang, 2016-03-19, Specification of an ISIS extension to support BIER domains and sub- domains. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2016-05-20, This document defines a YANG data model for BIER configuration and operation. "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, 2016-06-30, Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information. These extensions are applicable in those multi-tenant data centers where BGP instead of IGP is deployed as an underlay for network reachability advertisement. These extensions may also be applicable in other scenarios. "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Santosh Pallagatti, 2016-03-21, 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. "Bit Indexed Explicit Replication (BIER) Problem Statement", Greg Shepherd, Andrew Dolganow, arkadiy.gulko@thomsonreuters.com, 2016-04-03, There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane to build and maintain end-to-end tree state per flow, impacting router state capacity and network convergence times. Multi-point tree building protocols are often considered complex to deploy and debug and may include mechanics from legacy use-cases and/or assumptions which no longer apply to the current use-cases. When multicast services are transiting a provider network through an overlay, the core network has a choice to either aggregate customer state into a minimum set of core states resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow tree state directly into the provider core state amplifying the network-wide state problem. "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Tony Przygienda, Andrew Dolganow, 2016-07-18, This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola, 2016-07-18, This document describes a passive performance measurement method for multicast service over Bit Index Explicit Replication (BIER) domain. "BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Gregory Mirsky, 2016-07-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 mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2016-07-25, This document defines a YANG data model for BIER configuration and operation. Benchmarking Methodology (bmwg) ------------------------------- "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", Al Morton, 2016-08-14, Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general purpose hardware. See the new version history section for updates. "Data Center Benchmarking Terminology", Lucien Avramov, jhrapp@gmail.com, 2016-04-27, The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network switches and routers in the data center. "Data Center Benchmarking Methodology", Lucien Avramov, jhrapp@gmail.com, 2016-04-27, 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, 2016-04-05, 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 Georgescu, Gabor Lencse, 2016-07-06, 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, 2016-07-08, This document defines terminology for benchmarking an SDN controller's control plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN controllers. The terms provided in this document help to benchmark SDN controller's performance independent of the controller's supported protocols and/or network services. A mechanism for benchmarking the performance of SDN controllers is defined in the companion methodology document. These two documents provide a standard mechanism to measure and evaluate the performance of various controller implementations. "Benchmarking Methodology for SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2016-07-08, This document defines the methodologies for benchmarking control plane performance of SDN controllers. Terminology related to benchmarking SDN controllers is described in the companion terminology document. SDN controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors have taken the approach of considering an SDN controller as a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. The intent of this document is to provide a standard mechanism to measure the performance of all controller implementations. "Benchmarking Virtual Switches in OPNFV", Maryam Tahhan, Billy O'Mahony, Al Morton, 2016-07-13, This memo describes the progress of the Open Platform for NFV (OPNFV) project on virtual switch performance "VSWITCHPERF". This project intends to build on the current and completed work of the Benchmarking Methodology Working Group in IETF, by referencing existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo begins to describe the additional considerations when virtual switches are implemented in general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure. Calendaring Extensions (calext) ------------------------------- "New Properties for iCalendar", Cyrus Daboo, 2016-08-22, 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. "Support for Icalendar Relationships", Michael Douglass, 2016-08-25, This specification updates RELATED-TO and introduces new iCalendar properties LINK, STRUCTURED-CATEGORY and REFID to allow better linking and grouping of iCalendar components and related data. "Event Publishing Extensions to iCalendar", Michael Douglass, 2016-08-25, This specification introduces a number of new iCalendar properties which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Link Management Protocol Extensions for Grid Property Negotiation", Qilei Wang, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang, 2016-03-21, ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which provides a new tool that operators can implement to provide a higher degree of network optimization than is possible with fixed-grid systems. This document describes the extensions to the Link Management Protocol (LMP) to negotiate link grid property between the adjacent DWDM nodes before the link is brought up. "GMPLS OSPF-TE Extensions in support of Flexi-grid DWDM networks", Xian Zhang, zhenghaomian@huawei.com, Ramon Casellas, Oscar de Dios, Daniele Ceccarelli, 2016-08-10, This memo describes the OSPF-TE extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. "OSPF-TE Link Availability Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2016-08-19, 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 to extend the Open Shortest Path First (OSPF) Generalized Multi-Protocol Label Switching (GMPLS). 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, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2016-08-19, A Packet switching network may contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment. Availability is typically used for describing the link during network planning. This document introduces an optional Availability TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a Label Switched Path (LSP) in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth. "A framework for Management and Control of DWDM optical interface parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, 2016-07-08, To ensure an efficient data transport, meeting the requirements requested by today's IP-services the control and management of DWDM interfaces is a precondition for enhanced multilayer networking and for an further automation of network provisioning and operation. This document describes use cases and requirements for the control and management of optical interfaces parameters according to different types of single channel DWDM interfaces. The focus is on automating the network provisioning process irrespective on how it is triggered i.e. by EMS, NMS or GMPLS. This document covers management as well as control plane considerations in different management cases of 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. "A Yang Data Model for WSON Optical Networks", Young Lee, Dhruv Dhody, Xian Zhang, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, 2016-07-20, This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in wavelength switched optical networks (WSONs). Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "CDN Interconnection Metadata", Ben Niven-Jenkins, Rob Murray, Matt Caulfield, Kevin Ma, 2016-08-28, 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 Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins, 2016-05-19, 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, 2016-08-15, The Request Routing Interface comprises (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, 2016-05-20, 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 on how these registries can be extended in the future. "URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le Faucheur, Ray van Brandenburg, Bill Downey, Michel Fisher, 2016-06-28, 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. The mechanism described can be used both in CDNI and single CDN scenarios. Crypto Forum (cfrg) ------------------- "Hash-Based Signatures", David McGrew, Michael Curcio, 2016-03-21, 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, 2016-07-17, This document describes a secure and highly-efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks). Also, this protocol provides resistance to server compromise in the context that an attacker, who obtained the password verifier from the server, must at least perform off-line dictionary attacks to gain any advantage in impersonating the user. The AugPAKE protocol is not only provably secure in the random oracle model but also the most efficient over the previous augmented PAKE protocols (SRP and AMP). "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Aziz Mohaisen, 2016-07-06, This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures withstand attacks using quantum computers. "Requirements for PAKE schemes", Joern-Marc Schmidt, 2016-09-05, Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG). "Edwards-curve Digital Signature Algorithm (EdDSA)", Simon Josefsson, Ilari Liusvaara, 2016-08-19, The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described. The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. "The memory-hard Argon2 password hash and proof-of-work function", Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2016-03-21, This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer oriented description together with sample code and test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", Shay Gueron, Adam Langley, Yehuda Lindell, 2016-08-29, This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 2016-01-08, This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. "Mapping RTP streams to CLUE Media Captures", Roni Even, Jonathan Lennox, 2016-08-27, 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, 2016-08-13, This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. "CLUE Protocol data channel", Christer Holmberg, 2016-08-09, This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. "CLUE Signaling", Paul Kyzivat, Lennard Xiao, Christian Groves, Robert Hansen, 2016-03-21, 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, 2016-08-13, The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. Internet Wideband Audio Codec (codec) ------------------------------------- "Updates to the Opus Audio Codec", Jean-Marc Valin, Koen Vos, 2016-09-01, This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716]. "Ambisonics in an Ogg Opus Container", Michael Graczyk, 2016-07-19, This document defines an extension to the Ogg format to encapsulate ambisonics coded using the Opus audio codec. Constrained RESTful Environments (core) --------------------------------------- "Representing CoRE Formats in JSON and CBOR", Kepeng Li, Akbar Rahman, Carsten Bormann, 2016-07-08, JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, 2016-07-08, 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, Christian Groves, 2016-07-08, 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. Editor's note: This version removes the observe notify functionality. Further work is needed on this draft to "Guidelines for HTTP-to-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2016-09-08, This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Carsten Bormann, Simon Lemay, Hannes Tschofenig, Klaus Hartke, Bill Silverajan, Brian Raymor, 2016-08-24, The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. "Media Types for Sensor Markup Language (SenML)", Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keränen, Carsten Bormann, 2016-07-08, This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. "CBOR Encoding of Data Modeled with YANG", Michel Veillette, Alexander Pelov, Abhinav Somaraju, Randy Turner, Ana Minaburo, 2016-07-08, This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049]. "Patch and Fetch Methods for Constrained Application Protocol (CoAP)", Peter Van der Stok, Carsten Bormann, Anuj Sehgal, 2016-08-10, The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Object Signing and Encryption (COSE)", Jim Schaad, 2016-09-10, Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. CURves, Deprecating and a Little more Encryption (curdle) --------------------------------------------------------- "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", Mark Baushke, 2016-09-07, This document adds recommendations for adoption of ssh-curves from the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential (MODP) Groups, and deprecates some previously specified Key Exchange Method algorithm names for the Secure Shell (SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying the set key exchange algorithms that currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange methods use the SHA-2 family of hashes. "Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", denis bider, 2016-09-12, This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. "Extension Negotiation in Secure Shell (SSH)", denis bider, 2016-09-05, This memo defines a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after completed key exchange. "Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure", Simon Josefsson, Jim Schaad, 2016-08-19, This document specify algorithm identifiers and ASN.1 encoding formats for Elliptical Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The Encoding for Public Key, Private Key and EdDSA digital signature structures is provided. "EdDSA for DNSSEC", Ondřej Surý, Robert Edmonds, 2016-04-18, This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. "Ed25519 public key algorithm for the Secure Shell (SSH) protocol", Ben Harris, 2016-05-04, This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. "Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)", Russ Housley, 2016-09-07, This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is a construction of the ChaCha stream cipher and Poly1305 authenticator. "Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", Russ Housley, 2016-09-08, This document describes the conventions for using Elliptic Curve Diffie-Hellamn (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). "Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)", Russ Housley, 2016-09-08, This document describes the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) in the Cryptographic Message Syntax (CMS). The conventions for Ed25519 and Ed448 are described, but Ed25519ph and Ed448ph are not used with the CMS. "More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)", Mark Baushke, 2016-09-13, This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 2016-07-31, 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. Deterministic Networking (detnet) --------------------------------- "Deterministic Networking Architecture", Norman Finn, Pascal Thubert, 2016-08-18, Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes (e.g. bridges or routers) along the path of the flow; 2) providing explicit routes for DetNet flows that do not rapidly change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data' in spite of the loss of a path. The capabilities can be managed by configuration, or by manual or automatic network management. "Deterministic Networking Use Cases", Ethan Grossman, Craig Gunther, Pascal Thubert, Patrick Wetterwald, Jean Raymond, Jouni Korhonen, Yu Kaneko, Subir Das, Yiyong Zha, Balazs Varga, Janos Farkas, Franz-Josef Goetz, Jürgen Schmitt, 2016-07-04, 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. "DetNet Data Plane Protocol and Solution Alternatives", Jouni Korhonen, Janos Farkas, Gregory Mirsky, Pascal Thubert, Zhuangyan, Lou Berger, 2016-09-14, This document identifies existing IP and MPLS, and other encapsulations that run over IP and/or MPLS data plane technologies that can be considered as the base line solution for deterministic networking data plane definition. "Deterministic Networking Problem Statement", Norman Finn, Pascal Thubert, 2016-04-05, This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties . Dynamic Host Configuration (dhc) -------------------------------- "Customizing DHCP Configuration on the Basis of Network Topology", Ted Lemon, Tomek Mrugalski, 2016-07-08, 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 explains their operation. "Secure DHCPv6", Sheng Jiang, Lishan Li, Yong Cui, Tatuya Jinmei, Ted Lemon, Dacheng Zhang, 2016-07-08, DHCPv6 includes no deployable security mechanism that can protect end-to-end communication between DHCP clients and servers. This memo describes a mechanism for using public key cryptography to provide such security. The mechanism provides encryption in all cases, and can be used for authentication based either on pre-sharing of authorized certificates, or else using trust-on-first-use. "DHCPv4 over DHCPv6 Source Address Option", Ian Farrer, Qi Sun, Yong Cui, 2016-06-29, DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It also describes a method for configuring the client with the IPv6 address of the border router so that the softwire can be established. It is designed to work in conjunction with the IPv4 address allocation process. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael Richardson, Sheng Jiang, Ted Lemon, Timothy Winters, 2016-06-27, This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring hosts with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315, the original DHCPv6 specification, and incorporates the stateless DHCPv6 extensions (RFC 3736) and prefix delegation (RFC 3633), clarifying the interactions between these modes of operation (RFC 7550) and providing a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC7083, RFC7550. "YANG Data Model for DHCPv6 Configuration", Yong Cui, Hao Wang, Linhui Sun, Ted Lemon, Ian Farrer, Sladjana Zoric, 2016-06-18, This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays and clients. "DHCPv6 Failover Protocol", Tomek Mrugalski, Kim Kinnear, 2016-07-01, DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers 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). "DHCPv6 Prefix Length Hint Issues", Tianxiang Li, Cong Liu, Yong Cui, 2016-07-26, DHCPv6 Prefix Delegation [RFC3633] allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. "Security of Messages Exchanged Between Servers and Relay Agents", Bernie Volz, Yogendra Pal, 2016-09-08, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not recommend encryption. And, with recent concerns about pervasive monitoring it is appropriate to provide recommendations for DHCPv4 and also improve the recommendations for DHCPv6. This document updates RFC1542 and RFC3315. "Forcerenew Reconfiguration Extensions for DHCPv4", Luyuan Fang, Deepak Bansal, Fabio Chiussi, 2016-05-13, This document extends the definition of the DHCPFORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the DHCPFORCERENEW message more suitable to reconfigure configuration parameters other than IP addresses, and aligns the behavior of the reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCPv6. "Generalized Source UDP Port of DHCP Relay", Naiming Shen, Enke Chen, 2016-08-19, This document extends the DHCP and DHCPv6 protocols for the UDP transport from relay agent to server and allows the port to be any valid number on the DHCP relay system. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2016-03-21, 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. "AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and Requirements", Hannes Tschofenig, Jouni Korhonen, Glen Zorn, Kervin Pillay, 2016-06-08, This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs. "Diameter Overload Rate Control", Steve Donovan, Eric Noel, 2016-03-18, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. Requirements "Diameter Agent Overload and the Peer Overload Report", Steve Donovan, 2016-06-22, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] 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, 2016-03-18, This document defines a mechanism for sharing of Diameter load information. [RFC7068] describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) [RFC7683] solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. "Diameter Credit-Control Application", Lyle Bertz, David Dolson, ylifshitz@sandvine.com, Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, John Loughney, 2016-07-08, This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Interoperability Issues Between DMARC and Indirect Email Flows", Franck Martin, Eliot Lear, Tim Draegen, Elizabeth Zwicky, Kurt Andersen, 2016-07-18, DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive 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 these interoperability issues, and presents possible methods for addressing them. "Authenticated Received Chain (ARC) Protocol", Kurt Andersen, John Rae-Grant, Brandon Long, J. Adams, Steven Jones, 2016-06-25, Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. "Recommended Usage of the Authenticated Received Chain (ARC)", Steven Jones, John Rae-Grant, J. Adams, Kurt Andersen, 2016-06-25, The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. This document will provide guidance in these areas. Distributed Mobility Management (dmm) ------------------------------------- "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Jerome Marcon, 2016-06-09, Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). "On Demand Mobility Management", Alper Yegin, Danny Moses, Kisuk Kweon, Jinsung Lee, Jungshin Park, 2016-07-06, 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, Lyle Bertz, 2016-03-21, This specification supports the separation of the Control-Plane for mobility- and session management from the Data-Plane. The protocol semantics abstract the configuration of Data-Plane nodes and applies it 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 Data- Plane rules issued by the mobility Control-Plane. The scope of the rules comprises traffic description 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, 2016-07-25, The document [RFC4908] proposes to rely on multiple Care-of Addresses (CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO; [RFC3963]) to enable Multihoming technology for Small-Scale Fixed Networks. In the continuation of [RFC4908], this document specifies a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile IPv6 [RFC5213]. This extension allows a multihomed Mobile Access Gateway (MAG) to register more than one proxy care-of-address to the Local Mobility Anchor (LMA). "LMA Controlled MAG Session Parameters", Dhananjay Patki, Sri Gundavelli, Jong-Hyouk Lee, Qiao Fu, Lyle Bertz, 2016-07-03, 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, 2016-07-01, In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP is remained unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when an HNP renumbering is happened. In this document, a solution to support the HNP renumbering is proposed, as an update of the PMIPv6 specification. "DMM Deployment Models and Architectural Considerations", Sri Gundavelli, Seil Jeon, 2016-08-22, This document identifies the deployment models for Distributed Mobility Management architecture. "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Alexandre Petrescu, Fred Templin, 2016-09-08, This document defines distributed mobility anchoring to meet diverse mobility needs in 5G Wireless and beyond. Multiple anchors and nodes with mobility functions work together to provide IP mobility support. A network or network slice may be configured with distributed mobility anchoring with the needed behaviors depending on the needs of mobility support. In the distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. Without ongoing session requiring session continuity, a flow can be re-started using a new IP prefix which is allocated from the new network and is therefore anchored to the new network. With ongoing session, the anchoring of the prior IP prefix may be relocated to the new network to enable session continuity. Domain Name System Operations (dnsop) ------------------------------------- "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, Paul Hoffman, 2016-09-15, This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers. "DNSSEC Roadblock Avoidance", Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy, 2016-08-11, This document describes problems that a Validating DNS resolver, stub-resolver or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. "Returning extra answers in DNS responses.", Warren Kumari, Zhiwei Yan, Wesley Hardaker, 2016-06-29, This document (re)introduces the ability to provide multiple answers in a DNS response. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2016-09-12, 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. ] [ Question for Working Group. It has been proposed that the string .ALT should be replaced with something else e.g. .NOT-DNS. As naming discussions in the IETF are always short, simple, and not controversial, we figured we should open these for discussion now. We would appreciate clear feedback on preference and rationale. ] "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2016-07-18, 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, 2016-07-25, 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, 2016-08-26, The DNS is a query / response protocol. Failure to respond or to respond correctly to queries causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other 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. "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", Duane Wessels, Warren Kumari, Paul Hoffman, 2016-07-08, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. This document describes two independent methods for validating resolvers to publish their referenced keys: an EDNS option and a differnt DNS query. The reason there are two methods instead of one is some people see significant problems with each method. Having two methods is clearly worse than having just one, but it is probably better for the Internet than having no way to gain the information from the resolvers. "Managing DS records from parent via CDS/CDNSKEY", Ólafur Guðmundsson, Paul Wouters, 2016-06-10, RFC7344 specifies how DNS trust can be partially 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 multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signalling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signalling of these DNSSEC status changes. Initial trust is considered in general to be a hard technical problem, this document sets forth reasonable policies that clarify and simplify the initial acceptance policy. "NXDOMAIN really means there is nothing underneath", Stephane Bortzmeyer, Shumon Huque, 2016-07-18, 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 RFC 2308 a bit so it updates both of them. "DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara, 2016-08-04, The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719. "Aggressive use of NSEC/NSEC3", Kazunori Fujiwara, Akira Kato, Warren Kumari, 2016-09-13, The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to generate negative answers within a range. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase resilience to certain DoS attacks in some circumstances. This document updates RFC4035 by allowing resolvers to generate negative answers based upon NSEC/NSEC3 records. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.This document is being collaborated on in Github at: https://github.com/wkumari/draft-ietf- dnsop-nsec-aggressiveuse. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Known / open issues [To be moved to Github issue tracker]: "DNS Session Signaling", Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Allison Mankin, Tom Pusateri, 2016-08-15, The EDNS(0) Extension Mechanism for DNS is explicitly defined to only have "per-message" semantics. This document defines a new Session Signaling Opcode used to carry persistent "per-session" type-length- values (TLVs), and defines an initial set of TLVs used to manage session timeouts and termination. "DNS wire-format over HTTP", Linjian Song, Paul Vixie, Shane Kerr, Runxia Wan, 2016-09-15, This memo introduces a way to tunnel DNS data over HTTP. This may be useful in any situation where DNS is not working properly, such as when there is middlebox misbehavior. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "On Interoperation of Labels Among Conventional DNS and Other Resolution Systems", Andrew Sullivan, 2016-07-03, Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. "DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2016-07-08, The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. "Privacy Extensions for DNS-SD", Christian Huitema, Daniel Kaiser, 2016-06-10, DNS-SD allows discovery of services published in DNS or MDNS. The publication normally discloses information about the device publishing the services. There are use cases where devices want to communicate without disclosing their identity, for example two mobile devices visiting the same hotspot. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. DDoS Open Threat Signaling (dots) --------------------------------- "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Stephane Fouant, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia, 2016-03-21, 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. "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", Andrew Mortensen, Robert Moskowitz, Tirumaleswar Reddy, 2016-07-08, This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Andrew Mortensen, Flemming Andreasen, Tirumaleswar Reddy, Christopher Gray, Rich Compton, Nik Teague, 2016-07-05, This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. DNS PRIVate Exchange (dprive) ----------------------------- "Specification for DNS over Datagram Transport Layer Security (DTLS)", Tirumaleswar Reddy, Dan Wing, Prashanth Patil, 2016-09-08, 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. This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over port 853. "Authentication and (D)TLS Profile for DNS-over-(D)TLS", Sara Dickinson, Daniel Gillmor, Tirumaleswar Reddy, 2016-07-08, This document describes how a DNS client can use a domain name to authenticate a DNS server that uses Transport Layer Security (TLS) and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles for DNS clients and servers implementing DNS-over-TLS and DNS-over- DTLS. Delay/Disruption Tolerant Networking (dtn) ------------------------------------------ "Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane, 2016-09-07, This Internet Draft presents a specification for Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. "Bundle Protocol Security Specification", Edward Birrane, Kenneth McKeever, 2016-07-06, This document defines a security protocol providing end to end data integrity and confidentiality services for the Bundle Protocol. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens, 2016-07-19, RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is all that is needed. Examples of such environments include alerts issued by a temperature sensor, burglar alarm, or chemical spill sensor. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. "Next-Generation Pan-European eCall", Randall Gellens, Hannes Tschofenig, 2016-08-01, This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Blocks for the eCall vehicle data and metadata/ control data. "Next-Generation Vehicle-Initiated Emergency Calls", Randall Gellens, Brian Rosen, Hannes Tschofenig, 2016-08-01, 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 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 primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the eCall metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit- switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. "A LoST extension to return complete and similar location info", Roger Marshall, Jeff Martin, Brian Rosen, 2016-07-18, This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as a compilation of CAtype xml elements within the existing LoST findServiceResponse message structure. 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, 2016-03-21, The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. Geographic JSON (geojson) ------------------------- "GeoJSON Text Sequences", Sean Gillies, 2016-09-09, A proposed standard for geographic data that can be parsed and produced incrementally. Global Routing Operations (grow) -------------------------------- "By default reject propagation when no policy is associated with a BGP peering session.", Jared Mauch, Job Snijders, 2016-05-10, This document defines the default behaviour of a BGP speaker when no explicit policy is associated with a BGP peering session. "BLACKHOLE BGP Community for Blackholing", Thomas King, Christoph Dietzel, Job Snijders, Gert Doering, Greg Hankins, 2016-08-12, This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named BLACKHOLE allows an origin AS to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix. "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions", Colin Petrie, Thomas King, 2016-07-08, This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to support the Advertisement of Multiple Paths in BGP extensions. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Lars Eggert, 2016-08-04, 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, 2016-08-04, 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, 2016-06-07, This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Julien Laganier, 2016-08-04, This document specifies a 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, 2016-09-09, This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "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 how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming, but the procedures are out of scope for this document and are specified elsewhere. This document obsoletes RFC 5206. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keränen, Jan Melen, Miika Komu, 2016-07-01, 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, 2016-09-08, 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, 2016-07-06, 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. "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, 2016-06-06, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to HIPv2. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. Home Networking (homenet) ------------------------- "Outsourcing Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2016-08-15, Designation of services and devices of a home network is not user friendly, and mechanisms should enable a user to designate services and devices inside a home network using names. In order to enable internal communications while the home network experiments Internet connectivity shortage, the naming service should be hosted on a device inside the home network. On the other hand, home networks devices have not been designed to handle heavy loads. As a result, hosting the naming service on such home network device, visible on the Internet exposes this device to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. As result, home networks may prefer not serving the naming service for the Internet, but instead prefer outsourcing it to a third party. This document describes a mechanisms that enables the Home Network Authority (HNA) to outsource the naming service to the Outsourcing Infrastructure. "DHCPv6 Options for Homenet Naming Architecture", Daniel Migault, Tomek Mrugalski, Chris Griffiths, Ralf Weber, Wouter Cloetens, 2016-08-15, Home network devices are usually constrained devices with reduced network and CPU capabilities. As such, a home network device exposing the authoritative naming service for its home network on the Internet may become vulnerable to resource exhaustion attacks. One way to avoid exposing these devices is to outsource the authoritative service to a third party, e.g. ISP. The Homenet Naming Authority (HNA) is the designated device in charge of outsourcing the service to a third party, which requires setting up an architecture. Such settings may be inappropriate for most end users. This document defines DHCPv6 options so any agnostic HNA can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. "Homenet Naming and Service Discovery Architecture", Ted Lemon, 2016-07-08, This document recommends a naming and service discovery resolution architecture for homenets. This architecture covers local and global publication of names, discusses security and privacy implications, and addresses those implications. The architecture also covers name resolution and service discovery for hosts on the homenet, and for hosts that roam off of the homenet and still need access to homenet services. "Homenet profile of the Babel routing protocol", Juliusz Chroboczek, 2016-07-08, This document defines the subset of the Babel routing protocol [RFC6126] and its extensions that a Homenet router must implement. "Home Networking Control Protocol", Markus Stenberg, Steven Barth, Pierre Pfister, 2016-07-08, 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 that supports routing based on both the source and destination address. Human Rights Protocol Considerations (hrpc) ------------------------------------------- "Research into Human Rights Protocol Considerations", Niels Oever, Corinne Cath, 2016-08-27, The proliferating convolution of Internet and society increases the impact of the Internet on the lives of individuals. Because of this, the design and development of the architecture of the Internet also has a growing impact on society. This has led to an broad recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in the development and management of the Internet [HRC2012] [UNGA2013] [NETmundial]. It has also been argued that the Internet should be strengthened as a human rights enabling environment [Brown]. This document provides a proposal for a vocabulary to discuss the relation between human rights and Internet protocols, an overview of the discussion in technical and academic literature and communities, a proposal for the mapping of the relation between human rights and technical concepts, and a proposal for guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations [RFC6973]. Discussion of this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/listinfo/hrpc Hypertext Transfer Protocol Authentication (httpauth) ----------------------------------------------------- "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2016-08-16, This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. "HTTP Authentication Extensions for Interactive Clients", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2016-08-16, This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2016-08-16, This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Hypertext Transfer Protocol (httpbis) ------------------------------------- "Opportunistic Security for HTTP", Mark Nottingham, Martin Thomson, 2016-06-20, This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/opp-sec . "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 2016-07-08, By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot directly carry characters outside the US-ASCII coded 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. "HTTP Client Hints", Ilya Grigorik, 2016-05-31, An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences. "Encrypted Content-Encoding for HTTP", Martin Thomson, 2016-06-29, This memo introduces a content-coding for HTTP that allows message payloads to be encrypted. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/encryption . "Deprecate modification of 'secure' cookies from non-secure origins", Mike West, 2016-09-05, This document updates RFC6265 by removing the ability for a non- secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set. This deprecation improves the isolation between HTTP and HTTPS origins, and reduces the risk of malicious interference. "The ORIGIN HTTP/2 Frame", Mark Nottingham, Erik Nygren, 2016-05-09, This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. "Same-Site Cookies", Mike West, Mark Goodwin, 2016-06-20, This document updates RFC6265 by defining a "SameSite" attribute which allows servers to assert that a cookie ought not to be sent along with cross-site requests. This assertion allows user agents to mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks. "A JSON Encoding for HTTP Header Field Values", Julian Reschke, 2016-07-08, This document establishes a convention for use of JSON-encoded field values in HTTP header fields. 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 . Working Group information can be found at ; source code and issues list for this draft can be found at . The changes in this draft are summarized in Appendix A. "Cache Digests for HTTP/2", Kazuho Oku, Mark Nottingham, 2016-07-08, This specification defines a HTTP/2 frame type to allow clients to inform the server of their cache's contents. Servers can then use this to inform their choices of what to push to clients. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/cache-digest . Interface to Network Security Functions (i2nsf) ----------------------------------------------- "Analysis of Existing work for I2NSF", Susan Hares, Robert Moskowitz, Dacheng Zhang, 2016-07-20, This document analyzes the current state of the art for security management devices and security devices technologies in industries and the existing IETF work/protocols that are relevant to the Interface to Network Security Function (I2NSF). The I2NSF focus is to define data models and interfaces in order to control and monitor the physical and virtual aspects of network security functions. "I2NSF Problem Statement and Use cases", Susan Hares, Linda Dunbar, Diego Lopez, Myo Zarny, Christian Jacquenet, 2016-07-08, This document describes the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. "Interface to Network Security Functions (I2NSF) Terminology", Susan Hares, John Strassner, Diego Lopez, Liang Xia, 2016-07-08, This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort. "Framework for Interface to Network Security Functions", Edward Lopez, Diego Lopez, Linda Dunbar, John Strassner, Xiaojun Zhuang, Joe Parrott, Ram Krishnan, Seetharama Durbha, Rakesh Kumar, Anil Lohiya, 2016-08-17, This document describes the framework for the Interface to Network Security Functions (I2NSF), and defines a reference model (including major functional components) for I2NSF. Network security functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions in which the packet is associated. Interface to the Routing System (i2rs) -------------------------------------- "Routing Information Base Info Model", Nitin Bahadur, Sriganesh Kini, Jan Medved, 2016-07-07, Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies a information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh Kini, Nitin Bahadur, 2016-07-03, This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. "A Data Model for Network Topologies", Alex Clemm, Jan Medved, Robert Varga, Tony Tkacik, Nitin Bahadur, Hariharan Ananthakrishnan, Xufeng Liu, 2016-07-29, 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, 2016-07-08, 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 Beeram, 2016-08-09, This document defines a YANG data model for layer 3 network topologies. "I2RS Ephemeral State Requirements", Jeffrey Haas, Susan Hares, 2016-08-29, 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, 2016-09-15, This presents security-related requirements for the I2RS protocol which provides a new interface to the routing system described in the I2RS architecture document (RFC7921). The I2RS protocol is a re-use protocol implemented by re-using portions of existing IETF protocols and adding new features to these protocols. The I2RS protocol re- uses security features of a secure transport (E.g. TLS, SSH, DTLS) such as encryption, message integrity, mutual peer authentication, and replay protection. The new security features I2RS adds are: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier which identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport. This document provides the detailed requirements for these security features. "I2RS Environment Security Requirements", Daniel Migault, Joel Halpern, Susan Hares, 2016-04-04, 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. "Filter-Based RIB Information Model", Sriganesh Kini, Susan Hares, Linda Dunbar, Anoop Ghanwani, Ram Krishnan, Dean Bogdanovic, Russ White, 2016-06-16, This document defines an information model associated with the I2RS ephemeral state for filter-based routing of IP packets via a Filter- based Routing Information Base (FB-RIB). FB-RIBs (ephemeral and non- ephemeral) are associated with specific interfaces interfaces on a routing device, and process packets received on these interfaces according a filtering policy. A filtering policy is a a minimalistic event-match_condition-action (ECA) policy with only one event - the reception of a frame/packet of data on an interface. The match conditions in the filter policy are n-tuple matches based on the content of the frame/packet or the time of its arrival. Filter-based policy allows actions which modifying the frame/packet, forward the frame or packet, or drop the frame/packet. Filter-Based Policy in FB-RIBs engages before any destination based routing so the FB-RIBs provide a destination-based default RIB that will be used if none of the filters are matched. "Filter-Based Packet Forwarding ECA Policy", Susan Hares, Qin Wu, Russ White, 2016-07-01, This document describes the yang data model for packet forwarding policy that filters received packets and forwards (or drops) the packets. Prior to forwarding the packets out other interfaces, some of the fields in the packets may be modified. If one considers the packet reception an event, this packet policy is a minimalistic Event-Match Condition-Action policy. This policy controls forwarding of packets received by a routing device on one or more interfaces on which this policy is enabled. The policy is composed of an ordered list of policy rules. Each policy policy rule contains a set of match conditions that filters for packets plus a set of actions to modify the packet and forward packets. The match conditions can match tuples in multiple layers (L1-L4, application), interface received on, and and other conditions regarding the packet (size of packet, time of day). The modify packet actions allow for setting things within the packet plus decapsulation and encapsulation packet. The forwarding actions include forwarding via interfaces, tunnels, or nexthops and dropping the packet. The policy model can be used with the session ephemeral (BGP Flow Specifications), reboot ephemeral state (I2RS ephemeral), and non-ephemeral routing/forwarding state (e.g. configuration state ). "Filter-Based RIB Data Model", Susan Hares, Sriganesh Kini, Linda Dunbar, Ram Krishnan, Dean Bogdanovic, Russ White, 2016-06-23, This document defines a data model to support the Filter-based Routing Information Base (RIB) Yang data models for I2RS. A routing system uses the Filter-based RIB to program FIB entries that process incoming packets by matching on multiple fields within the packet and then performing a specified action on it. The FB-RIB can also specify an action to forward the packet according to the FIB entries programmed using the RIBs of its routing instance. Internet Architecture Board (iab) --------------------------------- "Confidentiality in the Face of Pervasive Surveillance", Ted Hardie, 2016-03-20, 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, 2016-09-12, Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions from one protocol or technology to another, throughout the protocol stack. 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. "Problems with the Public Key Infrastructure (PKI) for the World Wide Web", Russ Housley, Karen O'Donoghue, 2016-05-12, This document describes some of the challenges facing the current Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) and considers promising improvements to address these challenges. Technical, process, and policy improvements to the WebPKI are considered. In addition, some technical considerations beyond WebPKI itself are considered. Hopefully the content of this document will help drive the Internet community toward wide spread adoption of some of the highlighted recommendations. "The "xml2rfc" version 3 Vocabulary", Paul Hoffman, 2016-06-22, 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 followup, RFC 7749. 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 . "RFC Format Framework", Heather Flanagan, 2016-06-23, The canonical format for the RFC Series has been plain-text, ASCII- encoded for several decades. After extensive community discussion and debate, the RFC Editor will be transitioning to XML as the canonical format using the XML2RFC version 3 vocabulary. Different publication formats will be rendered from that base document. These changes are intended to increase the usability of the RFC Series by offering documents that match the needs of a wider variety of stakeholders. With these changes, however, comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that describes the problems being solved and summarizes the many documents that capture the specific requirements for each aspect of the change in format. "CSS Requirements for RFCs", Heather Flanagan, 2016-07-04, The HTML format for RFCs, described in [I-D.iab-html-rfc] assigns style guidance to an RFC Editor-defined Cascading Style Sheet (CSS). The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in draft-iab-html-rfc. Discussion of this draft takes place on the rfc-interest mailing list (rfc-interest@rfc-editor.org), which has its home page at https://www.rfc-editor.org/mailman/listinfo/rfc-interest. "SVG Drawings for RFCs: SVG 1.2 RFC", Nevil Brownlee, IAB, 2016-02-25, . Maybe the text in section This document specifies SVG 1.2 RFC - an SVG profile for use in diagrams that may appear in RFCs - and considers some of the issues concerning the creation and use of such diagrams. "RFC v3 Prep Tool Description", Paul Hoffman, Joe Hildebrand, 2016-06-30, This document describes some aspects of the "prep tool" that is expected to be created when the new RFC v3 specification is deployed. "HyperText Markup Language Request For Comments Format", Joe Hildebrand, Paul Hoffman, 2016-06-30, In order to meet the evolving needs of the Internet community, the format for RFCs is changing from a plain-text, ASCII-only format to a canonical XML format that will in turn be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft. "Requirements for Plain-Text RFCs", Heather Flanagan, 2016-05-16, In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC6949, "RFC Series Format Requirements and Future Development." Plain text remains an important format for many in the IETF community, and will be one of the publication formats rendered from the XML. This draft documents the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. "PDF for an RFC Series Output Document Format", Tony Hansen, Larry Masinter, Matthew Hardy, 2016-05-17, This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF. "Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016", Jaime Jimenez, Hannes Tschofenig, Dave Thaler, 2016-05-25, This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIWS], which took place in Santa Clara, CA, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and standards developing organizations to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop. "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report", Kathleen Moriarty, Mat Ford, 2016-06-03, The Internet Architecture Board (IAB) and the Internet Society (ISOC) hosted a day-long Coordinating Attack Response at Internet Scale (CARIS) workshop on 18 June 2015 in coordination with the Forum for Incident Response and Security Teams (FIRST) Conference in Berlin. The workshop included members of the FIRST community, attack response working group representatives, network and security operators, Regional Internet Registry (RIR) representatives, researchers, vendors, and representatives from standardisation communities. Key goals of the workshop were to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives. The workshop also aimed to provide the attendees with greater awareness of existing efforts to mitigate specific types of attacks, and greater understanding of the options available to collaborate and engage with these efforts. "IETF ICANN Root Zone Evolution Review Committee Appointment Procedures", Cindy Morgan, 2016-08-31, This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC). Interactive Connectivity Establishment (ice) -------------------------------------------- "ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", Paal-Erik Martinsen, Tirumaleswar Reddy, Prashanth Patil, 2016-08-03, 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 Keränen, Christer Holmberg, Jonathan Rosenberg, 2016-06-23, 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, 2016-09-08, 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 and Security Considerations", Kostas Pentikousis, Borje Ohlman, Elwyn Davies, Spiros Spirou, Gennaro Boggia, 2016-04-12, This document presents a number of considerations regarding evaluating Information-centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics. "CCNx Semantics", marc.mosko@parc.com, Ignacio Solis, Christopher Wood, 2016-06-28, This document describes the core concepts of the CCNx architecture and presents a minimum network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a Control message called an InterestReturn, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. "CCNx Messages in TLV Format", marc.mosko@parc.com, Ignacio Solis, Christopher Wood, 2016-06-28, 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, 2016-06-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. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 2016-07-08, Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. "Extended Optional Parameters Length for BGP OPEN Message", Enke Chen, John Scudder, 2016-06-28, The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we update RFC 4271 by extending the BGP OPEN length field in a backward-compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. "Best Practices for Advertisement of Multiple Paths in IBGP", Jim Uttaro, Pierre Francois, Keyur Patel, Jeffrey Haas, Adam Simpson, Roberto Fragassi, 2016-04-25, Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. "Assigned BGP extended communities", Bruno Decraene, Pierre Francois, 2016-07-07, This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. "Dissemination of Flow Specification Rules for IPv6", Danny McPherson, Robert Raszuk, Burjiz Pithawala, akarch@cisco.com, Susan Hares, 2016-03-19, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, Kevin Wang, 2016-07-08, This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per peer. Best path selection can also be performed based on user configured policies in each route reflector. "Extended Message support for BGP", Randy Bush, Keyur Patel, David Ward, 2016-06-21, 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 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, 2016-05-31, 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. "Accelerated Routing Convergence for BGP Graceful Restart", Keyur Patel, Enke Chen, Rex Fernando, John Scudder, 2016-06-07, In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 2016-06-07, 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. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Clarence Filsfils, David Smith, Juan Alcaide, Pradosh Mohapatra, 2016-03-21, This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. "Inter-domain SLA Exchange Attribute", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 2016-08-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, often manual, process and prone to errors. This document specifies an optional transitive attribute to signal SLA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks in situations where BGP is available as a routing protocol. "BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions", Stefano Previdi, Qin Wu, Hannes Gredler, Saikat Ray, jefftant@gmail.com, Clarence Filsfils, Les Ginsberg, 2016-05-11, This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in IS-IS and OSPF protocols. "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Stefano Previdi, Jie Dong, Mach Chen, Hannes Gredler, jefftant@gmail.com, 2016-07-06, This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a router and advertise it into BGP-LS updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. "BGP Extensions for Service-Oriented MPLS Path Programming (MPP)", Zhenbin Li, Shunwan Zhuang, Sujian Lu, 2016-05-05, Service-oriented MPLS programming (SoMPP) is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to download programmed MPLS path and map the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming. "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Jie Dong, Mach Chen, Robert Raszuk, 2016-05-31, The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2016-05-09, 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, 2016-08-08, The routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setup and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network. "Advertising Node Admin Tags in BGP Link-State Advertisements", Pushpasis Sarkar, Hannes Gredler, Stephane Litkowski, 2016-05-13, This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. "Dissemination of Flow Specification Rules for L2 VPN", Hao Weiguo, liangqiandeng, Stephane Litkowski, Shunwan Zhuang, 2016-05-17, This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. "Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang, Qin Wu, Jeff Tantsura, 2016-06-06, As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE. "Segment Routing BGP Egress Peer Engineering BGP-LS Extensions", Stefano Previdi, Clarence Filsfils, Saikat Ray, Keyur Patel, Jie Dong, Mach Chen, 2016-05-12, Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. "Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen, 2016-09-02, Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. 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, 2016-05-31, 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. "Carrying Label Information for BGP FlowSpec", liangqiandeng, Susan Hares, Jianjie You, Robert Raszuk, danma@cisco.com, 2016-03-21, This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. "BGP FlowSpec Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang Ou, Yujia Luo, Sujian Lu, Shunwan Zhuang, Nan Wu, 2016-06-17, This document describes a mechanism to use BGP Flowspec address family as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- FS RPD). "BGP Model for Service Provider Networks", Anees Shaikh, Rob Shakir, Keyur Patel, Susan Hares, Kevin D'Souza, Deepak Bansal, Alex Clemm, Alex Zhdankin, Mahesh Jethanandani, Xufeng Liu, 2016-07-17, 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, 2016-07-08, [I-D.ietf-grow-route-leak-problem-definition] provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in a new optional transitive attribute, called BGP RLP attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. "Inter-domain SLA Exchange Implementation Report-02", Shitanshu Shah, Keyur Patel, 2016-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, 2016-05-31, RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. "Segment Routing Prefix SID extensions for BGP", Stefano Previdi, Clarence Filsfils, Acee Lindem, Keyur Patel, Arjun Sreekantiah, Saikat Ray, Hannes Gredler, 2016-06-16, 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, 2016-08-16, 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. "Flowspec Indirection-id Redirect", Gunter Van de Velde, Wim Henderickx, Keyur Patel, Arjun Sreekantiah, Zhenbin Li, Shunwan Zhuang, Nan Wu, 2016-07-08, Flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particularly if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new extended community known as redirect-to- indirection-id (32-bit) flowspec action to provide advanced redirection capabilities on flowspec clients. When activated, the flowspec extended community is used by a flowspec client to find the correct next-hop entry within a localised indirection-id mapping table. The functionality present in this draft allows a network controller to decouple flowspec functionality from the creation and maintainance of the network's service plane itself including the setup of tunnels and other service constructs that could be managed by other network devices. "BGP Link-State extensions for Segment Routing", Stefano Previdi, Peter Psenak, Clarence Filsfils, Hannes Gredler, Mach Chen, jefftant@gmail.com, 2016-07-06, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. "BGP Flow-Spec Redirect to Tunnel Action", Hao Weiguo, Zhenbin Li, Lucy Yong, 2016-03-18, This draft defines a new flow-spec action, Redirect-to-Tunnel, and a new sub-TLV for Redirect-to-Tunnel extended community. A BGP UPDATE for a flow-spec NLRI can contain the extended community. When activated, the corresponding flow packets will be encapsulated and carried via a tunnel. The redirect tunnel information is encoded in BGP Path Attribute or extended community [TUNNELENCAPS][MPP] that is carried in the BGP flow-spec UPDATE. The draft expends the tunnel encapsulation attribute [TUNNELENCAPS] to apply to flow-spec SAFI, i.e., 133 and 134. "Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro, Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2016-03-16, [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation "BGP FlowSpec Redirect to Generalized Segment ID Action", Zhenbin Li, Shunwan Zhuang, Nan Wu, 2016-03-21, This document defines a new type of the redirect extended community, called as Redirect to Generalized Segment ID Extended Community. When activated, the Redirect to Generalized Segment ID Extended Community is used by BGP FlowSpec Controller to signal the specific redirecting action to BGP Flowspec Client, and then the BGP Flowspec Client will use the Generalized Segment ID and the Segment Type to find a local forwarding entity in a local mapping table. "Dissemination of Flow Specification Rules for NVO3", Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu, 2016-05-17, This draft proposes a new subset of component types to support the NVO3 flow-spec application. "Applying BGP flowspec rules on a specific interface set", Stephane Litkowski, Adam Simpson, Keyur Patel, Jeffrey Haas, 2016-06-08, BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. "BGP Flow Specification Filter for MPLS Label", Lucy Yong, Susan Hares, liangqiandeng, Jianjie You, 2016-05-31, This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. "Carrying Label Information for BGP FlowSpec", liangqiandeng, Susan Hares, Jianjie You, Robert Raszuk, danma@cisco.com, 2016-06-01, This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. "BGP Flow Specification Packet-Rate Action", Wesley Eddy, Justin Dailey, Gilbert Clark, 2016-06-06, This document defines a new type of traffic filtering action for the BGP flow specification. The new packet-rate action allows specifying a rate-limit in number of packets per second. This is intended to be used in combatting some types of denial of service attacks where the packet rate is more important than the raw bitrate of the attack traffic. "Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro, Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2016-07-08, [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2016-08-31, Flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particularly if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new extended community known as redirect-to- indirection-id (32-bit) flowspec action to provide advanced redirection capabilities on flowspec clients. When activated, the flowspec extended community is used by a flowspec client to find the correct next-hop entry within a localised indirection-id mapping table. The functionality present in this draft allows a network controller to decouple flowspec functionality from the creation and maintainance of the network's service plane itself including the setup of tunnels and other service constructs that could be managed by other network devices. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Gonzalo Salgueiro, Chris Pearce, Paul Giralt, 2016-08-18, 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. While the identifier is intended to work across multiple protocols, this document describes its usage in SIP. This document also describes a backwards compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document. This document obsoletes RFC 7329. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, Chidambaram Arunachalam, 2016-07-07, 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, 2016-08-14, 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, 2016-07-06, This document discusses the role of IP tunnels in the Internet architecture, in which IP datagrams are carried as payloads in non- link layer protocols. It explains their relationship to existing protocol layers and the challenges in supporting IP tunneling based on the equivalence of tunnels to links. "IP over Intentionally Partially Partitioned Links", Erik Nordmark, 2016-07-08, 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, Rolf Winter, 2016-07-08, Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threads. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 2016-07-20, 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, 2016-07-08, 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, 2016-07-08, This document defines the format for the Performance Metrics registry and defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", Nalini Elkins, Rob Hamilton, mackermann@bcbsm.com, 2016-09-14, To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. "Initial Performance Metric Registry Entries", Al Morton, Marcelo Bagnulo, Philip Eardley, Kevin D'Souza, 2016-07-08, This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * All section 4 and 5 parameters reference YANG types for alternate data formats. * implementation of standard naming format for parameters. Still need: * revisions that follow section 4 changes in proposed metrics defined in sections 6, 7, 8. "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Al Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, Lianshu Zheng, 2016-07-08, This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). We define the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specify it using YANG. "Alternate Marking method for passive performance monitoring", Giuseppe Fioccola, Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Mach Chen, Lianshu Zheng, Gregory Mirsky, Tal Mizrahi, 2016-07-07, This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)", Gregory Mirsky, Israel Meilik, 2016-06-17, This document describes an OPTIONAL feature for active performance measurement protocols allowing use of time stamp format defined in IEEE-1588v2-2008. "IPv6 Updates for IPPM's Active Metric Framework", Al Morton, Joachim Fabini, Nalini Elkins, mackermann@bcbsm.com, Vinayak Hegde, 2016-07-04, This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with new considerations for measurement methodology and testing. The memo updates the definition of standard-formed packets in RFC 2330 to include IPv6 packets. It also augments distinguishing aspects of packets, referred to as Type-P for test packets in RFC 2330. Two points (at least) are worthwhile discussing further: extent of coverage for 6LO and IPv6 Header Compression, and the continued need to define a "minimal standard-formed packet". IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks", Yoav Nir, Valery Smyslov, 2016-09-12, This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) 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, 2016-08-30, This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. "Postquantum Preshared Keys for IKEv2", Scott Fluhrer, David McGrew, Panos Kampanakis, 2016-08-04, This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys "Algorithm Implementation Requirements and Usage Guidance for IKEv2", Yoav Nir, Tero Kivinen, Paul Wouters, Daniel Migault, 2016-09-12, The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", Daniel Migault, John Mattsson, Paul Wouters, Yoav Nir, Tero Kivinen, 2016-09-09, This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. "TCP Encapsulation of IKE and IPsec Packets", Tommy Pauly, Samy Touati, Ravi Mantha, 2016-08-17, This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Routing with Reverse Metric", Naiming Shen, Shane Amante, Mikael Abrahamsson, 2016-08-25, This document describes the mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to- point or multi-access LAN interface by signaling to an adjacent IS-IS neighbor with the metric towards itself during network maintenance or other operational events. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, Jeff Tantsura, 2016-06-13, 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. "YANG Data Model for IS-IS protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Zhaohui Zhang, Ladislav Lhotka, 2016-03-21, 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 configuration and operation. "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT)", Zhenbin Li, Nan Wu, Quintin <>, Alia Atlas, Chris Bowers, Jeff Tantsura, 2016-05-18, 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. "ISIS Auto-Configuration", Bing Liu, Bruno Decraene, Ian Farrer, Mikael Abrahamsson, Les Ginsberg, 2016-07-20, This document specifies IS-IS auto-configuration mechanisms. The key components are IS-IS System ID self-generation, duplication detection and duplication resolution. These mechanisms provide limited IS-IS functions, thus they are fit for the networks where plug-and-play configuration is expected. "IS-IS Minimum Remaining Lifetime", Les Ginsberg, Paul Wells, Bruno Decraene, Tony Przygienda, Hannes Gredler, 2016-08-17, Corruption of the Remainining Lifetime Field in a Link State PDU can go undetected. In certain scenarios this may cause or exacerbate flooding storms. It is also a possible denial of service attack vector. This document defines a backwards compatible solution to this problem. "IS-IS Extensions for Advertising Router Info", Les Ginsberg, Stefano Previdi, Mach Chen, 2016-08-18, This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971. "Advertising L2 Bundle Member Link Attributes in IS-IS", Les Ginsberg, Jerome Marcon, Clarence Filsfils, Stefano Previdi, Mohan Nanduri, Ebben Aries, 2016-08-23, There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of layer 2 (L2) bundle members. "IS-IS Multi-Instance", Les Ginsberg, Stefano Previdi, Wim Henderickx, 2016-05-10, This draft describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System To Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type Length Value (TLV) identifying the instance and the topology(ies) to which the PDU belongs. This draft updates RFC 6822 if approved. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "CFRG ECDH and signatures in JOSE", Ilari Liusvaara, 2016-08-18, This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JOSE. Javascript Object Notation Update (jsonbis) ------------------------------------------- "The JavaScript Object Notation (JSON) Data Interchange Format", Tim Bray, 2016-06-15, 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. Font Top Level Media Type (justfont) ------------------------------------ "The font Top Level Type", Chris Lilley, 2016-05-03, This memo serves to register and document the "font" Top Level Type, under which the Internet Media subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "AES Encryption with HMAC-SHA2 for Kerberos 5", Michael Jenkins, Michael Peck, Kelley Burgin, 2016-08-26, 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. "Anonymity Support for Kerberos", Larry Zhu, Paul Leach, Sam Hartman, Shawn Emery, 2016-09-05, This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as historic. RFC 6112 contained errors and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. "Generic Security Service API Version 2: Java Bindings Update", Mayank Upadhyay, Seema Malkani, Wang Weijun, 2016-04-06, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension", Michiko Short, Seth Moore, Paul Miller, 2016-05-23, 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. "Authentication Indicator in Kerberos Tickets", Anupam Jain, Nathan Kinder, Nathaniel McCallum, 2016-05-16, This document specifies an extension in the Kerberos protocol [RFC4120]. It defines a new authorization data type AD- AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in the service tickets so that application services can use it as an input into policy decisions. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer Schatzmayr, Wim Henderickx, 2016-03-21, 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. "A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing Liu, Giles Heron, 2016-03-21, This document defines a YANG data model for the configuration and management of Keyed IPv6 tunnels. The data model includes both configuration and state data. Due to the stateless nature of keyed IPv6 tunnels, a model for NETCONF notifications is not necessary. L3VPN Service Model (l3sm) --------------------------- "YANG Data Model for L3VPN service delivery", Stephane Litkowski, Luis Tomotaki, Kenichi Ogaki, Kevin D'Souza, 2016-09-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. Limited Additional Mechanisms for PKIX and SMIME (lamps) -------------------------------------------------------- "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Message Specification", Jim Schaad, Blake Ramsdell, Sean Turner, 2016-08-29, This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.5. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. "Internationalized Email Addresses in X.509 certificates", Alexey Melnikov, Wei Chuang, 2016-07-24, This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. "Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 3.2 Certificate Handling", Jim Schaad, Blake Ramsdell, Sean Turner, 2016-08-29, This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. Layer Independent OAM Management in the Multi-Layer Environment (lime) ---------------------------------------------------------------------- "Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Qin Wu, Zitao Wang, 2016-07-08, This document presents a base YANG Data model for connection oriented OAM protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface) "Generic YANG Data Model for Connection Less Operations, Administration, and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu, Reshad Rahman, Srihari Raghavan, 2016-09-12, This document presents a base YANG Data model for connectionless OAM protocols. It provides a technology-independent abstraction of key OAM constructs for connectionless protocols. The Based model presented here can be extended to include technology specific details. This is leading to uniformity between OAM protocols and support nested OAM workflows (i.e., performing OAM functions at different or same levels through a unified interface). Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP EID Block", Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller, 2016-02-26, 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, 2016-04-13, 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 Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job Snijders, 2016-07-20, 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. "LISP Delegated Database Tree", Vince Fuller, Darrel Lewis, Vina Ermagan, Amit Jain, Anton Smirnov, 2016-09-08, This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", Albert Cabellos-Aparicio, Damien Saucez, 2015-04-02, This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. "LISP EID Block Management Guidelines", Luigi Iannone, Roger Jorgensen, David Conrad, Geoff Huston, 2016-04-06, This document proposes a framework for the management of the LISP EID Address Block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations. "LISP Data-Plane Confidentiality", Dino Farinacci, Brian Weis, 2016-06-29, 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, 2016-07-07, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2016-04-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. "LISP Experimental Message & IANA Registry for LISP Packet Type Allocations", Mohamed Boucadair, Christian Jacquenet, 2016-09-08, This document defines a registry for LISP Packet Type allocations. It also specifies a shared LISP message type for experimentation purposes. 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, 2016-08-19, This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. "A YANG Data Model for LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2016-07-08, 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, 2016-07-08, This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keränen, 2016-01-04, This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Mohit Sethi, Jari Arkko, Ari Keränen, Heidi-Maria Back, 2016-09-06, This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some preliminary experiences in implementing small devices using those libraries, and discusses trade-offs involving different types of approaches. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Shawn Jury, Darryl Satterwhite, Rick Taylor, Jerome Marcon, 2016-07-26, 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 Version 2 (AODVv2) Routing", Charles Perkins, Stan Ratliff, John Dowdell, Lotte Steenbrink, Victoria Mercieca, 2016-05-04, 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. "Security Threats for Simplified Multicast Forwarding (SMF)", Jiazi Yi, Thomas Clausen, Ulrich Herberg, 2016-08-26, This document analyzes security threats of the Simplified Multicast Forwarding (SMF) mechanism, including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. This document also updates RFC7186 regarding the threats to relay set selection mechanisms using RFC6130. "Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Jiazi Yi, Benoit Parrein, 2016-07-25, This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. "Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Thomas Clausen, Ulrich Herberg, Jiazi Yi, 2016-09-01, 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, 2016-05-04, RFC 5444 specifies a generalized MANET packet/message format and describes an intended use to multiplex MANET routing protocol messages that is mandated for use by RFC 5498. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses of RFC 5444 that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use optional generic RFC 5444 parsers. "Credit Windowing extension for DLEP", Stan Ratliff, 2016-04-10, This draft describes an extension to 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, 2016-08-13, This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a query and receives a reply. "Use of Multicast Across Inter-Domain Peering Points", Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, Ram Krishnan, 2016-07-28, 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. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "IODEF Usage Guidance", Panos Kampanakis, Mio Suzuki, 2016-07-08, The Incident Object Description Exchange Format v2 [I-D.ietf-mile-rfc5070-bis] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practicioners to develop tools that can leverage IODEF for incident sharing. This document provides guidelines for IODEF practicioners. It also addresses 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, 2016-06-24, The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with XML Schema. This new information and data model obsoletes Request for Comment (RFC) 5070 and 6685. "MILE Implementation Report", Christopher Inacio, daisu-mi@nc.u-tokyo.ac.jp, 2016-06-07, This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups. "Resource-Oriented Lightweight Information Exchange", John Field, Stephen Banghart, David Waltermire, 2016-07-08, This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share and exchange representations of security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as Web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations. "XMPP Protocol Extensions for Use with IODEF", Nancy Cam-Winget, Syam Appala, Scott Pope, 2016-04-19, This document describes the extensions made to Extensible Messaging and Presence Protocol (XMPP) [RFC6120]that enables the use of XMPP as a transport protocol for collecting and distributing any security telemetry information between and among network platforms, endpoints, and most any network connected device. Specifically, this document will focus on how these extensions can be used to transport the Incident Object Description Exchange Format (IODEF) information. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "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, 2016-06-22, 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, 2016-08-30, 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', '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, 2016-08-17, This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. "WebRTC MediaStream Identification in the Session Description Protocol", Harald Alvestrand, 2016-07-07, This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. "Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)", Marc Petit-Huguenin, Ari Keränen, Suhas Nandakumar, 2016-07-22, This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar, 2016-06-27, The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Thomas Stach, Enrico Marocco, Christer Holmberg, 2016-08-09, 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, 2016-06-28, In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. "SDP-based Data Channel Negotiation", Keith Drage, Maridi Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2016-07-25, The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. "MSRP over Data Channels", Keith Drage, Maridi Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2016-07-25, This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). "Using the SDP Offer/Answer Mechanism for DTLS", Christer Holmberg, Roman Shpount, 2016-07-18, 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. The draft updates RFC 5763 and RFC 7345, by replacing common SDP offer/ answer procedures with a reference to this specification. This draft defines a new SDP media-level attribute, 'dtls-id'. "RTP Payload Format Constraints", Peter Thatcher, Mo Zanaty, Suhas Nandakumar, Bo Burman, Adam Roach, Byron Campen, 2016-07-18, In this specification, we define a framework for specifying constraints on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and constrain the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the constraints defined by this document. "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", Christer Holmberg, 2016-08-08, This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. "Updates to RFC 4572", Christer Holmberg, 2016-06-10, This document updates RFC 4572 by clarifying the usage of multiple SDP 'fingerprint' attributes with a single TLS connection. The document also updates the preferred cipher suite with a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint that is used to calculate the certificate signature. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------------------------------------------ "Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom McGarry, 2016-07-08, The functions of the public switched telephone network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including telephone numbers (TNs). TNs no longer serve simply as telephone routing addresses, they are now identifiers which may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment, and proposes a framework for Internet-based services relying on TNs. Multiprotocol Label Switching (mpls) ------------------------------------ "Hitless path segment monitoring", Alessandro D'Alessandro, Loa Andersson, Satoshi Ueno, Kaoru Arai, Yoshinori Koike, 2016-05-31, One of the most important OAM capabilities for transport network operation is fault localisation. An in-service, on-demand segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between end points. However, the current segment monitoring approach defined for MPLS RFC 6371 [RFC6371] has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support a Hitless Path Segment Monitoring (HPSM). "MPLS Transport Profile Linear Protection MIB", Kingston Smiler, Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin, Jeong-dong Ryoo, 2016-08-08, 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. "Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL)", Nobo Akiya, George Swallow, Carlos Pignataro, Andrew Malis, Sam Aldrin, 2016-09-05, Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity verification method and Traceroute as a fault isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP Ping and Traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply non-EL-based load balancing (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP which can be EL- based or non-EL-based. This document extends the MPLS LSP Ping and Traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs which make use of the EL. This document updates RFC 6790. "LDP Extensions to Support Maximally Redundant Trees", Alia Atlas, Kishore Tiruveedhula, Chris Bowers, Jeff Tantsura, IJsbrand Wijnands, 2016-05-18, 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, Luay Jalil, Uma Chunduri, Kamran Raza, 2016-06-01, Recent targeted LDP (tLDP) applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- label bindings over the session. "Entropy labels for source routed tunnels with label stacks", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir, jefftant@gmail.com, 2016-07-08, Source routed tunnels with label 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 tunnels with label stacks. "RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon, Tarek Saad, Nicholas Tan, Abhishek Deshmukh, Markus Jork, Vishnu Beeram, 2016-03-18, This document defines RSVP-TE signaling extensions that reduce the amount of RSVP signaling required for Fast Reroute (FRR) procedures and subsequently improve the scalability of the RSVP-TE signaling when undergoing FRR convergence post a link or node failure. Such extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) to be independent of the number of protected Label Switched Paths (LSP)s traversing between them (eg. when bypass LSP FRR protection is used). The new signaling extensions are fully backwards compatible with nodes that do not support them. "Residence Time Measurement in MPLS network", Gregory Mirsky, Stefano Ruffini, Eric Gray, John Drake, Stewart Bryant, Sasha Vainshtein, 2016-07-20, 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. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Gregory Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2016-09-13, Bidirectional Forwarding Detection (BFD) is expected to be able to monitor wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct egress BFD peer to use specific path for the 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, 2016-06-14, 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, 2016-07-08, 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, Mach Chen, Zhenbin Li, Carlos Pignataro, Gregory Mirsky, 2016-08-25, 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. "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", Kireeti Kompella, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Mach Chen, 2016-07-03, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. "Use Cases and Requirements for MPLS-TP multi-failure protection", Zhenlong Cui, Rolf Winter, Himanshu Shah, Sam Aldrin, Masahiro Daikoku, 2016-08-16, For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. "LDP Specification", Xia Chen, Loa Andersson, Nicolai Leymann, Ina Minei, Kamran Raza, 2016-04-07, The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. "Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode", Jeong-dong Ryoo, Tae-sik Cheung, Huub van Helvoort, Italo Busi, Guangjuan Weng, 2016-09-15, This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic, in which the state machine resides, when operating in APS mode, and clarify some operation related to state transition table lookup. "Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane", Nagendra Kumar, George Swallow, Carlos Pignataro, Nobo Akiya, Sriganesh Kini, Hannes Gredler, Mach Chen, 2016-05-13, Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to MPLS data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with a Segment Routing header. The segment assignment and forwarding semantic nature of Segment Routing raises additional consideration for connectivity verification and fault isolation in LSP with Segment Routing architecture. This document illustrates the problem and describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS data plane. "A YANG Data Model for MPLS Base", Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Tarek Saad, Igor Bryskin, Xia Chen, Raqib Jones, Bin Wen, 2016-07-08, This document contains a specification of the the MPLS base YANG model. The MPLS base YANG module serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE models) will augment the MPLS base YANG model. "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Kamran Raza, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Himanshu Shah, Igor Bryskin, Xia Chen, Raqib Jones, Bin Wen, 2016-07-08, This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on LER(s) and LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). "Refresh Interval Independent FRR Facility Protection", Chandrasekar R, Ina Minei, Dante Pacella, Tarek Saad, 2016-08-15, RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the LSP related states along the reserved path. In the absence of refresh messages, the LSP related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP-TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale. RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much larger than the default 30 seconds defined in RFC 2205. However, the protocol extensions defined in RFC 4090 for supporting fast reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states. In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. Coupling LSP state with the corresponding RSVP-TE signaling adjacencies as recommended in RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC 4090 FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh-interval Independent RSVP FRR (RI- RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in scenarios not covered by procedures defined in RSVP-TE Scaling Recommendations. "YANG Data Model for MPLS LDP and mLDP", Kamran Raza, Rajiv Asati, Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, 2016-08-18, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP) and Multipoint LDP (mLDP). "Using BGP to Bind MPLS Labels to Address Prefixes", Eric Rosen, 2016-09-16, This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch, 2016-07-06, TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824 [RFC6824] through clarifications and modifications primarily driven by deployment experience. "Use Cases and Operational Experience with Multipath TCP", Olivier Bonaventure, Christoph Paasch, Gregory Detal, 2016-08-29, 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. Meeting Venue (mtgvenue) ------------------------- "IAOC Plenary Meeting Venue Selection Process", Fred Baker, 2016-07-06, This documents the IAOC's IETF Meeting Venue Selection Process from the perspective of its goals and thought processes. It points to additional process documents on the IAOC Web Site that go into further detail and are subject to change with experience. "IAOC Plenary Meeting Venue Selection Process", Ray Pelletier, Laura Nugent, Dave Crocker, Lou Berger, Ole Jacobsen, Jim Martin, Fred Baker, 2016-08-22, This documents the IAOC's IETF Meeting Venue Selection Process from the perspective of its goals and thought processes. It points to additional process documents on the IAOC Web Site that go into further detail and are subject to change with experience. Network Configuration (netconf) ------------------------------- "RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen, 2016-08-15, This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. "YANG Patch Media Type", Andy Bierman, Martin Bjorklund, Kent Watsen, 2016-08-15, This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. "Zero Touch Provisioning for NETCONF or RESTCONF based Management", Kent Watsen, Mikael Abrahamsson, 2016-07-08, This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). "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. "Subscribing to YANG datastore push updates", Alex Clemm, Alberto Prieto, Eric Voit, Ambika Tripathy, Einar Nilsen-Nygaard, 2016-06-16, 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 a receiver per a subscription policy, without requiring additional client requests. "System Keychain Model", Kent Watsen, Gary Wu, 2016-07-08, This document defines a YANG data module for a system-level keychain mechanism, that might be used to hold onto private keys and certificates that are trusted by the system advertising support for this module. "TLS Client and Server Models", Kent Watsen, 2016-07-08, This document defines two YANG modules, one defines groupings for a generic TLS client and the other defines groupings for a generic TLS server. It is intended that these groupings will be used by applications using the TLS protocol. "RESTCONF Client and Server Models", Kent Watsen, Jürgen Schönwälder, 2016-07-08, This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. "SSH Client and Server Models", Kent Watsen, Gary Wu, 2016-07-09, This document defines two YANG modules, one defines groupings for a generic SSH client and the other defines groupings for a generic SSH server. It is intended that these groupings will be used by applications using the SSH protocol. "NETCONF Client and Server Models", Kent Watsen, Gary Wu, Jürgen Schönwälder, 2016-07-09, This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. "NETCONF Support for Event Notifications", Alberto Prieto, Alexander Clemm, Eric Voit, Einar Nilsen-Nygaard, Ambika Tripathy, Sharon Chisholm, Hector Trevino, 2016-09-08, This document defines the support of [event-notifications] by the Network Configuration protocol (NETCONF). [event-notifications] describes capabilities and operations for providing asynchronous message notification delivery. This document discusses how to provide them on top of NETCONF. The capabilities and operations defined between this document and [event-notifications] are intended to obsolete RFC 5277. "Restconf and HTTP Transport for Event Notifications", Eric Voit, Alex Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Alberto Prieto, 2016-09-08, This document defines Restconf, HTTP, and HTTP2 bindings for the transport Subscription requests and corresponding push updates. Being subscribed may be both Event Notifications and YANG Datastores. "Subscribing to Event Notifications", Alexander Clemm, Alberto Prieto, Eric Voit, Einar Nilsen-Nygaard, Ambika Tripathy, Sharon Chisholm, Hector Trevino, 2016-09-14, This document defines capabilities and operations for providing asynchronous message notification delivery for notifications, such as those defined using YANG. Notification delivery can occur over a variety of protocols used commonly in conjunction with YANG, such as NETCONF and RESTCONF. The capabilities and operations defined in this document along with their mapping onto NETCONF transport are intended to replace RFC 5277. NETCONF Data Modeling Language (netmod) --------------------------------------- "A YANG Data Model for Routing Management", Ladislav Lhotka, Acee Lindem, 2016-08-18, This document contains a specification of three YANG modules and one submodule. 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 control plane protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions -- routes, routing information bases (RIB), and control plane protocols. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2016-09-01, 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. "Syslog YANG Model", Clyde Wildes, Kiran Koushik, 2016-07-08, This document describes a data model for the configuration of syslog. "Network Access Control List (ACL) YANG Data Model", Dean Bogdanovic, Kiran Koushik, Lisa Huang, Dana Blair, 2016-07-08, This document describes a data model of Access Control List (ACL) basic building blocks. "Terminology and Requirements for Enhanced Handling of Operational State", Kent Watsen, Thomas Nadeau, 2016-01-22, This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. "YANG Module Classification", Dean Bogdanovic, Benoit Claise, Carl Moberg, 2016-06-22, 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 (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules 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 modules. A consistent terminology would help with the categorization of YANG modules, 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 modules. "YANG Schema Mount", Martin Bjorklund, Ladislav Lhotka, 2016-07-01, This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. "Common Interface Extension YANG Data Models", Robert Wilton, David Ball, tsingh@juniper.net, Selvakumar Sivaraj, 2016-07-07, This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. "A YANG Data Model for Entity Management", Andy Bierman, Martin Bjorklund, Jie Dong, Dan Romascanu, 2016-05-13, This document defines a YANG data model for the management of multiple physical entities managed by a single server. Internet Video Codec (netvc) ---------------------------- "