Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. Generated 2015-07-15 06:08:35 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "IPv6 over BLUETOOTH(R) Low Energy", Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez, 2015-06-25, Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques. "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel, 2015-07-03, DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 20 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE such as for Internet of Things applications. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques. "Transmission of IPv6 over MS/TP Networks", Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson, 2015-07-06, Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer, which is used extensively in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. "Transmission of IPv6 Packets over Near Field Communication", Joo-Sang Youn, Yong-Geun Hong, 2015-07-05, Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques. IPv6 Maintenance (6man) ----------------------- "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 2015-06-09, IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the "Identification" field is that the corresponding value must be different than that employed for any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for selecting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. "Privacy Considerations for IPv6 Address Generation Mechanisms", Alissa Cooper, Fernando Gont, Dave Thaler, 2015-06-26, This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. "Recommendation on Stable IPv6 Interface Identifiers", Fernando Gont, Alissa Cooper, Dave Thaler, Shucheng LIU, 2015-07-06, The IPv6 addressing architecture defines Modified EUI-64 format Interface Identifiers, and the existing IPv6 over various link-layers specify how such identifiers are derived from the underlying link- layer address (e.g., an IEEE LAN MAC address) when employing IPv6 Stateless Address Autoconfiguration (SLAAC). The security and privacy implications of embedding link-layer addresses in the Interface Identifier have been known and understood for some time now, and some popular IPv6 implementations have already deviated from such schemes to mitigate these issues. This document changes the recommended default Interface Identifier generation scheme for SLAAC to that specified in RFC7217, and recommends against embedding link- layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and RFC5121, which require IPv6 Interface Identifiers to be derived from the underlying link-layer address. Additionally, this document provides advice about the generation of Interface Identifiers with other address configuration mechanisms, such as Dynamic Host Configuration Protocol version 6 (DHCPv6) and manual configuration. "Deprecating the Generation of IPv6 Atomic Fragments", Fernando Gont, Shucheng LIU, Tore Anderson, 2015-07-04, The core IPv6 specification requires that when a host receives an ICMPv6 "Packet Too Big" message reporting an MTU smaller than 1280 bytes, the host includes a Fragment Header in all subsequent packets sent to that destination, without reducing the assumed Path-MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can be forged, coupled with the widespread filtering of IPv6 fragments, results in an attack vector that can be leveraged for Denial of Service purposes. This document briefly discusses the aforementioned attack vector, and formally updates RFC2460 such that generation of IPv6 atomic fragments is deprecated, thus eliminating the aforementioned attack vector. "Validation of IPv6 Neighbor Discovery Options", Fernando Gont, Ron Bonica, Shucheng LIU, 2015-03-09, This memo specifies validation rules for IPv6 Neighbor Discovery (ND) Options. In order to avoid pathological outcomes, IPv6 implementations validate incoming ND options using these rules. "IPv6 Router Advertisement Options for DNS Configuration", Jaehoon Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli, 2015-05-08, This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document obsoletes RFC 6106 and allows a higher default value of the lifetime of the RA DNS options to avoid the frequent expiry of the options on links with a relatively high rate of packet loss. "IPv6 Neighbor Discovery Optional RS/RA Refresh", Erik Nordmark, Andrew Yourtchenko, Suresh Krishnan, 2015-05-19, 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 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Pascal Thubert, 2015-05-14, This document is the first volume of the 6TiSCH architecture of an IPv6 Multi-Link subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4 TSCH low-power wireless networks attached and synchronized by Backbone Routers. The architecture defines mechanisms to establish and maintain routing and scheduling in a centralized, distributed, or mixed fashion. "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2015-07-06, 6TiSCH proposes an architecture for an IPv6 multi-link subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4e TSCH wireless networks attached and synchronized by backbone routers. This document extends existing terminology documents available for Low-power and Lossy Networks to provide additional terminology elements. "Minimal 6TiSCH Configuration", Xavier Vilajosana, Kris Pister, 2015-07-06, This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fall- back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development. "6TiSCH Operation Sublayer (6top) Interface", Qin Wang, Xavier Vilajosana, 2015-07-06, This document defines a generic data model for the 6TiSCH Operation Sublayer (6top), using the YANG data modeling language. This data model can be used for network management solutions defined by the 6TiSCH working group. "6TiSCH Resource Management and Interaction using CoAP", Raghuram Sudhaakar, Pouria Zand, 2015-03-09, The [IEEE802154e] standardizes the TSCH mode of operation and defines the mechanisms for layer 2 communication between conforming devices. 6top defines a set of commands to monitor and manage the TSCH schedule. To realize the full functionality of sensor networks and allow their adoption and use in real applications we need additional mechanisms. Specifically, the interaction with 6top, control and modify schedules, monitor parameters etc must be defined. Higher layers monitoring and management entities are then able to use these capabilities to create feedback loops. Although, there have been many custom implementations of such feedback loops between the routing, transport and MAC layers in sensor network deployments, there has been a lack of standards based approaches. This draft defines the messaging between monitoring and management entities and the 6top layer and a mapping to the 6top commands. The document also presents a particular implementation of the generic data model specified in [I-D.ietf-6tisch-6top-interface] based on CoAP and CBOR. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Josh Howlett, Sam Hartman, Alejandro Perez-Mendez, 2015-02-06, This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, users or machines (Clients). These Clients may be named using a NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, 2012-09-25, Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear, Jim Schaad, 2014-07-21, Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. "Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations", Rhys Smith, 2015-07-06, 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) ------------------------------------------------------------------- "ACE use cases", Ludwig Seitz, Stefanie Gerdes, Goran Selander, Mehdi Mani, Sandeep Kumar, 2015-06-05, Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, Stefano Previdi, Michael Scharf, 2015-06-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. "Multi-Cost ALTO", Sabine Randriamasy, Wendy Roome, Nico Schwan, 2015-05-22, The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. For example, when downloading a file that is mirrored on several sites, a user application may use these ALTO cost metrics to determine the most efficient mirror site. An ALTO Server may offer a variety of cost metrics, based on latency, bandwidth, hop count, jitter, or whatever else the ALTO Server deems useful. When selecting a mirror site, a client may consider more than one metric, perhaps trading bandwidth for latency. While the base ALTO Protocol allows a client to use more than one cost metric, to do so, the client must request each metric separately. This document defines a new service that allows a client to retrieve several cost metrics with one request, which is considerably more efficient. In addition, this document extends the ALTO constraint tests to allow a user to specify an arbitrary logical combination of tests on several cost metrics. "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y. Yang, 2015-05-29, The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information to client applications so that clients may make informed decisions. To that end, an ALTO Server provides Network and Cost Maps. Using those maps, an ALTO Client can determine the costs between endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to those maps, other than by periodically re-fetching them. Because the maps may be large (potentially tens of megabytes), and because only parts of the maps may change frequently (especially Cost Maps), that can be extremely inefficient. Therefore this document presents a mechanism to allow an ALTO Server to provide updates to ALTO Clients. Updates can be both immediate, in that the server can send updates as soon as they are available, and incremental, in that if only a small section of a map changes, the server can send just the changes. ART Area General Applications Working Group (appsawg) ----------------------------------------------------- "The text/markdown Media Type", Sean Leonard, 2015-06-19, This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. "Message Disposition Notification", Tony Hansen, Alexey Melnikov, 2015-07-04, 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. "The file URI Scheme", Matthew Kerwin, 2015-05-28, This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It attemps to define a common core which is intended to interoperate across the broad spectrum of existing implementations, while at the same time documenting other current practices. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 2015-06-04, This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. "text/markdown Use Cases", Sean Leonard, 2015-06-18, This document elaborates upon the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied. Active Queue Management and Packet Scheduling (aqm) --------------------------------------------------- "The Benefits to Applications of using Explicit Congestion Notification (ECN)", Michael Welzl, Gorry Fairhurst, 2015-03-09, This document describes the potential benefits to applications when they enable Explicit Congestion Notification (ECN). It outlines the principal gains in terms of increased throughput, reduced delay and other benefits when ECN is used over network paths that include equipment that supports ECN-marking. The focus of this document is on usage of ECN, not its implementation in hosts, routers and other network devices. "AQM Characterization Guidelines", N. Kuhn, Preethi Natarajan, Naeem Khademi, David Ros, 2015-07-06, Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet scheduling scheme such as fair queuing. The IETF Active Queue Management and Packet Scheduling working group was formed to standardize AQM schemes that are robust, easily implementable, and successfully deployable in today's networks. This document describes various criteria for performing precautionary characterizations of AQM proposals. This document also helps in ascertaining whether any given AQM proposal should be taken up for standardization by the AQM WG. "On Queuing, Marking, and Dropping", Fred Baker, Rong Pan, 2015-05-01, This note discusses implementation strategies for coupled queuing and mark/drop algorithms. "The Benefits of using Explicit Congestion Notification (ECN)", Gorry Fairhurst, Michael Welzl, 2015-06-20, 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 ECN-marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN, nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers or other network devices. "Controlled Delay Active Queue Management", Kathleen Nichols, Van Jacobson, Andrew McGregor, Jana, 2015-04-27, The "persistently full buffer" problem has been discussed in the IETF community since the early 80's [RFC896]. The IRTF's End-to-End Working Group called for the deployment of active queue management (AQM) to solve the problem in 1998 [RFC2309]. Despite the awareness, the problem has only gotten worse as Moore's Law growth in memory density fueled an exponential increase in buffer pool size. Efforts to deploy AQM have been frustrated by difficult configuration and negative impact on network utilization. This problem, recently christened "bufferbloat", [TSVBB2011] [BB2011] has become increasingly important throughout the Internet but particularly at the consumer edge. 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, 2015-03-27, Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. We present here a lightweight design, PIE (Proportional Integral controller Enhanced) that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. "FlowQueue-Codel", Toke Hoeiland-Joergensen, Paul McKenney, dave.taht@gmail.com, Jim Gettys, Eric Dumazet, 2015-07-04, This memo presents the FQ-CoDel hybrid packet scheduler/AQM algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. "A PIE-Based AQM for DOCSIS Cable Modems", Greg White, Rong Pan, 2015-03-28, DOCSIS cable modems provide broadband Internet access to over one hundred million users worldwide. They are commonly positioned at the head of the bottleneck link for traffic in the upstream direction (from the customer), and 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 includes 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. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "AES-GCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, Kevin Igoe, 2015-06-30, This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. "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-05-29, This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the RTP Control Protocol (RTCP). 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-07-06, This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Colin Perkins, Varun Singh, 2015-03-23, The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP "circuit-breakers". Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. "RTP Topologies", Magnus Westerlund, Stephan Wenger, 2015-07-02, This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and replaces RFC 5117. "Sending Multiple Media Streams in a Single RTP Session", Jonathan Lennox, Magnus Westerlund, Wenson Wu, Colin Perkins, 2015-07-06, 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 media 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 Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Jonathan Lennox, Magnus Westerlund, Wenson Wu, Colin Perkins, 2015-07-06, RTP allows multiple media 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 co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. "Multipath RTP (MPRTP)", Varun, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 2015-07-06, The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints. "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2015-03-24, This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) packets are multiplexed on a single receiving socket. It overrides the guidance from SRTP Extension for DTLS [RFC5764], which suffered from three issues described and fixed in this document. "The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon, 2015-05-29, This document defines SRTP crypto suites based on the ARIA block cipher algorithm for use with the Session Description Protocol (SDP) security descriptions. Audio/Video Transport Extensions (avtext) ----------------------------------------- "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", Jonathan Lennox, Kevin Gross, Suhas Nandakumar, Gonzalo Salgueiro, Bo Burman, 2015-06-23, The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources, and defines common terminology for discussing protocol entities and their relationships. "RTP Stream Pause and Resume", Bo Burman, Azam Akram, Roni Even, Magnus Westerlund, 2015-07-03, With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli, 2015-04-28, Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. "RTP Header Extension for RTCP Source Description Items", Magnus Westerlund, Bo Burman, Roni Even, Mo Zanaty, 2015-07-06, Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. "The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2015-07-06, This memo describes the RTP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several scalable media formats. BGP Enabled Services (bess) --------------------------- "BGP ACCEPT_OWN Community Attribute", Jim Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 2015-06-24, Under certain conditions it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one Virtual Routing and Forwarding (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router than the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, and to be used in a standard manner throughout an autonomous system. "BGP-signaled end-system IP/VPNs.", Pedro Marques, Luyuan Fang, Nischal Sheth, Maria Napierala, Nabil Bitar, 2014-10-02, This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs is used to provide a Virtual Network service to end-systems. These end-systems may be used to provide network services or may directly host end-to-end applications. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2015-04-27, [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]. "Inter-AS Option D for BGP/MPLS IP VPN", Manu Pathak, Keyur Patel, Arjun Sreekantiah, 2015-05-28, This document describes a new option known as an Inter-AS option D to the 'Multi-AS Backbones' section of [RFC4364]. This option combines VPN VRFs at the Autonomous System Border Router (ASBR) as described in 'Option A' with the distribution of labeled VPN-IP routes as described in 'Option B'. In addition, this option allows for a data plane consisting of two methods of traffic forwarding between attached ASBR pairs. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Florin Balus, Keyur Patel, Ali Sajassi, 2015-07-04, This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. "A Network Virtualization Overlay Solution using EVPN", Ali Sajassi, John Drake, Nabil Bitar, Aldrin Isaac, Jim Uttaro, Wim Henderickx, 2015-02-25, 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. "Extranet Multicast in BGP/IP MPLS VPNs", Yakov Rekhter, Eric Rosen, Rahul Aggarwal, Yiqun Cai, Thomas Morin, 2015-05-07, Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide MVPN extranet service. "Global Table Multicast with BGP-MVPN Procedures", Jeffrey Zhang, Leonard Giuliano, Eric Rosen, Karthik Subramanian, Dante Pacella, Jason Schiller, 2015-05-18, RFC6513, RFC6514, and other RFCs describe protocols and procedures which a Service Provider (SP) may deploy in order offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN- specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the very same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the MVPN BGP procedures for Global Table Multicast. "Ingress Replication Tunnels in Multicast VPN", Eric Rosen, Karthik Subramanian, Jeffrey Zhang, 2015-05-11, RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to- multipoint trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be "directly connected" to its child nodes. When a parent node has to send a multicast data packet to its child nodes, it does not use layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. "Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication", Jeffrey Zhang, Yakov Rekhter, Andrew Dolganow, 2015-01-14, RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document describes how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. This enables a Service Provider to use Ingress Replication to offer transparent BIDIR-PIM service to its VPN customers. "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Ali Sajassi, Dennis Cai, 2015-07-06, This document describes how Network Virtualization Overlay networks (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both. "FIB Reduction in Virtual Subnet", Xiaohu Xu, Susan Hares, Fan Yongbing, Christian Jacquenet, Truman Boyes, Brendan Fee, Wim Henderickx, 2015-01-26, Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution which is intended for building Layer3 network virtualization overlays within and/or across 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, Florin Balus, Aldrin Isaac, 2015-03-09, EVPN provides a flexible control plane that allows intra-subnet connectivity in an IP/MPLS and/or an NVO-based network. In NVO networks, there is also a need for a dynamic and efficient inter- subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and may not support their own routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route- type is used. "VPWS support in EVPN", Sami Boutros, Ali Sajassi, Samer Salam, John Drake, Jeff Tantsura, Dirk Steinberg, Thomas Beckhaus, Jorge Rabadan, 2015-06-29, This document describes how EVPN can be used to support virtual private wire service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for single-segment and multi-segment PW signaling, and provides fast protection using data-plane prefix independent convergence upon node or link failure. "Multicast VPN state damping", Thomas Morin, Stephane Litkowski, Keyur Patel, Jeffrey Zhang, Robert Kebler, Jeffrey Haas, 2015-02-10, This document describes procedures to damp multicast VPN routing state changes and control the effect of the churn due to the multicast dynamicity in customer site. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control plane load increase in the core routing infrastructure. New procedures are proposed inspired from BGP unicast route damping principles, but adapted to multicast. "(PBB-)EVPN Seamless Integration with (PBB-)VPLS", Ali Sajassi, Samer Salam, Nick Regno, Jorge Rabadan, 2015-02-21, This draft discusses the backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. "IANA Registry for P-Multicast Service Interface Tunnel Attribute Flags", Eric Rosen, 2015-02-24, RFC6514 defines the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". This attribute contains an octet of "flags". Only one flag is defined in that RFC, but there is now a need to define additional flags. Since the RFC did not create a registry for the assignment of flag bits, this document updates the RFC by creating a registry for that purpose. "BGP as an MVPN PE-CE Protocol", Keyur Patel, Eric Rosen, Yakov Rekhter, 2015-04-06, When a Service Provider offers BGP/MPLS IP VPN service to its customers, RFCs 6513 and 6514 describe protocols and procedures that the Service Provider can use in order to carry the customer's IP multicast traffic from one customer site to others. BGP can be used to carry customer multicast routing information from one Provider Edge (PE) router to another, but it is assumed that PIM is running on the interface between a Customer Edge (CE) router and a PE router. This document specifies protocols and procedures that, under certain conditions, allow customer multicast routing information to carried between PE and CE via BGP. This can eliminate the need to run PIM on the PE-CE interfaces, potentially eliminating the need to run PIM on the PE routers at all. "Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution", Xiaohu Xu, Robert Raszuk, Christian Jacquenet, Truman Boyes, Brendan Fee, 2015-06-01, This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as Virtual Subnet, which can be used for building Layer3 network virtualization overlays within and/or between data centers. "E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, Sami Boutros, Jim Uttaro, Aldrin Isaac, 2015-07-06, The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK] proposes a solution framework for supporting this service in MPLS networks. This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 2015-02-19, 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, 2015-02-20, This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R, Sergio Murillo, 2015-03-23, The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks, 2015-05-06, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. "BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2015-04-24, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. "Seamless Bidirectional Forwarding Detection (BFD) Use Case", Manav Bhatia, Satoru Matsushima, Greg Mirsky, Nagendra Kumar, 2015-04-28, This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that extensions could be developed to allow for simplified detection of forwarding failures. "Seamless Bidirectional Forwarding Detection (S-BFD)", Nobo Akiya, Carlos Pignataro, David Ward, Manav Bhatia, Juniper Networks, 2015-06-19, This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS", Nobo Akiya, Carlos Pignataro, David Ward, 2015-06-20, This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. "Clarifications to RFC 5884", Vengada Govindan, Kalyani Rajaraman, Greg Mirsky, Nobo Akiya, Sam Aldrin, 2015-06-16, This document clarifies the procedures for establishing, maintaining and removing multiple, concurrent BFD sessions for a given described in RFC5884. "Yang Data Model for Bidirectional Forwarding Detection (BFD)", Lianshu Zheng, Reshad Rahman, Juniper Networks, Mahesh Jethanandani, Greg Mirsky, 2015-07-06, This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). "BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks, 2015-05-06, 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. Bit Indexed Explicit Replication (bier) --------------------------------------- "Bit Indexed Explicit Replication (BIER) Problem Statement", Greg Shepherd, Andrew Dolganow, arkadiy.gulko@thomsonreuters.com, 2015-02-06, 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. "Multicast using Bit Index Explicit Replication", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Tony Przygienda, Sam Aldrin, 2015-06-25, This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification. "OSPF Extensions For BIER", Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Jeffrey Zhang, Sam Aldrin, 2015-04-27, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the OSPF protocol extension required for BIER with MPLS encapsulation. "Encapsulation for Bit Index Explicit Replication in MPLS Networks", IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam Aldrin, 2015-06-05, Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies the BIER encapsulation to be used in an MPLS network. "Multicast VPN Using BIER", Eric Rosen, Mahesh Sivakumar, IJsbrand Wijnands, Sam Aldrin, Andrew Dolganow, Tony Przygienda, 2015-07-06, The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network. "BIER Use Cases", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, arkadiy.gulko@thomsonreuters.com, Dom Robinson, 2015-04-27, 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, Sam Aldrin, Jeffrey Zhang, Tony Przygienda, 2015-04-28, Specification of an ISIS extension to support BIER domains and sub- domains. Benchmarking Methodology (bmwg) ------------------------------- "Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence", Rajiv Papneja, Bhavani Parise, Susan Hares, Dean Lee, Ilya Varlashkin, 2015-01-16, BGP is widely deployed and used by several service providers as the default Inter AS routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP Benchmarking Methodology using existing BGP Convergence Terminology, RFC 4098. "Traffic Management Benchmarking", Barry Constantine, Ram (Ramki) Krishnan, 2015-06-09, This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e. policing, shaping, etc.). The goal is to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic. "ISSU Benchmarking Methodology", Sarah Banks, Fer, Gery Czirjak, Ramdas Machat, 2015-05-31, Modern forwarding devices attempt to minimize any control and data plane disruptions while performing planned software changes, by implementing a technique commonly known as In Service Software Upgrade (ISSU) This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event. "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", Al Morton, 2015-06-02, Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in commodity off-the-shelf hardware. Version NOTES: Addressed Barry Constantine's comments throughout the draft, see: http://www.ietf.org/mail-archive/web/bmwg/current/msg03167.html AND, comments from the extended discussion during IETF-92 BMWG session: "Data Center Benchmarking Terminology", Lucien Avramov, jhrapp@gmail.com, 2015-06-18, The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network equipment in the data center. "Data Center Benchmarking Methodology", Lucien Avramov, jhrapp@gmail.com, 2015-06-18, The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. "Benchmarking IPv6 Neighbor Cache Behavior", William Cerveny, Ron Bonica, 2015-07-02, This document is a benchmarking instantiation of RFC 6583: "Operational Neighbor Discovery Problems" [RFC6583]. It describes a general testing procedure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes. Calendaring Extensions (calext) ------------------------------- "Calendar Availability", Cyrus Daboo, Mike Douglass, 2015-03-23, This document specifies a new iCalendar calendar component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including iTIP free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed. This document also defines extensions to CalDAV calendar-access and calendar-auto-schedule which specify how this new calendar component should be used when doing free-busy time evaluation in CalDAV. "New Properties for iCalendar", Cyrus Daboo, 2015-04-06, This document defines a set of new properties for iCalendar data as well as extending the use of some existing properties to the entire iCalendar object. Common Control and Measurement Plane (ccamp) -------------------------------------------- "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 2014-05-22, This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength- Switched Optical network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as Optical-Electronic-Optical (OEO) switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, Sugang Xu, Young Lee, Giovanni Martinelli, Hiroaki Harai, 2015-05-18, This document provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSON). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. "Framework and Requirements for GMPLS-based control of Flexi-grid DWDM networks", Oscar Gonzalez de Dios, Ramon Casellas, 2015-05-25, To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new dense wavelength division multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such an environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum creating what is known as a flexible grid (flexi- grid). This document defines a framework and the associated control plane requirements for the GMPLS-based control of flexi-grid DWDM networks. "Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers", Adrian Farrel, Daniel King, Yao Li, Fatai Zhang, 2015-07-02, GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFC 3471 and RFC 6205 by introducing a new label format. "RSVP-TE Signaling Extensions in support of Flexible Grid", Fatai Zhang, Xian Zhang, Adrian Farrel, Oscar Gonzalez de Dios, Daniele Ceccarelli, 2015-01-29, This memo describes the extensions to the Resource reserVation Protocol Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. "Link Management Protocol Extensions for Grid Property Negotiation", Xihua Fu, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang, 2015-03-09, 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 Flexible Grid", Xian Zhang, zhenghaomian@huawei.com, Ramon Casellas, Oscar Gonzalez de Dios, Daniele Ceccarelli, 2015-06-16, This memo describes the OSPF-TE extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. "Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation", Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Andrea Zanardi, Domenico Siracusa, Federico Pederzolli, Young Lee, Fatai Zhang, 2015-03-09, This document defines an information model to support Impairment- Aware (IA) Routing and Wavelength Assignment (RWA) functionality. This information model extends the information model for impairment- free RWA process in WSON to facilitate computation of paths where optical impairment constraints need to considered. "OSPF Routing Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2015-07-05, A packet switching network MAY contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links MAY change discretely in reaction to changing external environment. Availability is typically used for describing such links during network planning. This document introduces an OPTIONAL ISCD Availability sub-TLV in OSPF routing protocol. This extension can be used for route computation in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth. "RSVP-TE Signaling Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2015-07-05, A Packet switching network MAY contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment. Availability is typically used for describing the link during network planning. This document introduces an Extended Ethernet Bandwidth Profile TLV and an OPTIONAL Availability sub-TLV in RSVP-TE signaling. This extension can be used to set up a label switching path (LSP) in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth. "IANA Allocation Procedures for OTN Signal Type Subregistry to the GMPLS Signaling Parameters Registry", Zafar Ali, Antonello Bonfanti, Matt Hartley, Fatai Zhang, 2015-03-09, IANA has defined an "OTN Signal Type" subregistry to the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. This draft proposes changes to the OTN Signal Type subregistry to include Specification Required policies, as defined in [RFC5226]. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTN", Zafar Ali, Antonello Bonfanti, Matt Hartley, Fatai Zhang, 2015-03-09, [RFC4328] and [RFC7139] provide the extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e and ODUflex. However, these specifications do not cover the additional signal types ODU1e, ODU3e1, and ODU3e2 mentioned in [G.Sup43]. This draft provides GMPLS signaling extensions for these additional signal types. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "CDN Interconnection Metadata", Ben Niven-Jenkins, Rob Murray, Matt Caulfield, Kevin Ma, 2015-07-06, The Content Delivery Networks Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI metadata and the protocol for exchanging that metadata. "CDNI Logging Interface", Francois Le Faucheur, Gilles Bertrand, Iuniana Oprescu, Roy Peterkofsky, 2015-07-06, This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. "CDNI Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins, 2015-07-02, This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. "Request Routing Redirection Interface for CDN Interconnection", Ben Niven-Jenkins, Ray van Brandenburg, 2015-07-02, The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI Request Routing Redirection interface. "CDNI Request Routing: Footprint and Capabilities Semantics", Jan Seedorf, Jon Peterson, Stefano Previdi, Ray van Brandenburg, Kevin Ma, 2015-03-09, This document tries to capture 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)" is expected to offer within CDNI. The document also provides guidelines for a CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines how these registries may be extended in the future. "URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le Faucheur, Ray van Brandenburg, Bill Downey, Michel Fisher, 2015-06-01, 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 algorithm includes specific provisions for allowing access control of HTTP Adaptive Streaming content that is characterized by independent chunks referenced by a manifest file. The proposed mechanism is also applicable in a non-CDNI context. Crypto Forum (cfrg) ------------------- "Dragonfly Key Exchange", Dan Harkins, 2015-06-18, This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and off-line dictionary attack. This document is a product of the Crypto Forum Research Group (CFRG). "Augmented Password-Authenticated Key Exchange (AugPAKE)", SeongHan Shin, Kazukuni Kobara, 2015-01-28, This document describes a secure and highly-efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks). Also, this protocol provides resistance to server compromise in the context that an attacker, who obtained the password verifier from the server, must at least perform off-line dictionary attacks to gain any advantage in impersonating the user. The AugPAKE protocol is not only provably secure in the random oracle model but also the most efficient over the previous augmented PAKE protocols (SRP and AMP). "SPAKE2, a PAKE", Watson Ladd, 2015-02-16, This Internet-Draft describes SPAKE2, a secure, efficient password based key exchange protocol. "Elliptic Curves for Security", Adam Langley, Rich Salz, spt, 2015-03-24, This memo describes an algorithm for deterministically generating parameters for elliptic curves over prime fields offering high practical security in cryptographic applications, including Transport Layer Security (TLS) and X.509 certificates. It also specifies a specific curve at the ~128-bit security level and a specific curve at the ~224-bit security level. "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Aziz Mohaisen, 2015-07-03, This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and, besides some special instantiations, is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures withstand attacks using quantum computers. "Requirements for PAKE schemes", Joern-Marc Schmidt, 2015-06-30, Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes and discusses their requirements. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 2015-04-13, This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. "Mapping RTP streams to CLUE media captures", Roni Even, Jonathan Lennox, 2015-03-08, This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano, 2015-06-29, This document provides an XML schema file for the definition of CLUE data model types. "CLUE Protocol data channel", Christer Holmberg, 2015-03-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, 2015-03-09, This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. "CLUE protocol", Roberta Presta, Simon Romano, 2015-04-22, The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. Internet Wideband Audio Codec (codec) ------------------------------------- "Ogg Encapsulation for the Opus Audio Codec", Timothy Terriberry, Ron Lee, Ralph Giles, 2015-07-06, This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format, capable of delivery over a reliable stream-oriented transport, without requiring all the data, or even the total length of the data, up-front, in a form that is identical to the on-disk storage format. Congestion Exposure (conex) --------------------------- "Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements", Matt Mathis, Bob Briscoe, 2014-10-24, This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. "IPv6 Destination Option for ConEx", Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo, 2014-11-10, ConEx is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. "TCP modifications for Congestion Exposure", Mirja Kuehlewind, Richard Scheffenegger, 2015-04-22, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). "Mobile Communication Congestion Exposure Scenario", Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Ying Zhang, Carlos Bernardos, 2014-09-17, This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. Constrained RESTful Environments (core) --------------------------------------- "Block-wise transfers in CoAP", Carsten Bormann, Zach Shelby, 2015-03-09, CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. "Observing Resources in CoAP", Klaus Hartke, 2014-12-30, The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. "Representing CoRE Formats in JSON and CBOR", Kepeng Li, Akbar Rahman, Carsten Bormann, 2015-07-06, JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. Group Communication for the Constrained Application Protocol (RFC7390) defines a number of JSON formats for controlling communication between groups of nodes employing the Constrained Application Protocol (CoAP). In a similar vein, this specification defines CBOR variants of these formats. "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, 2015-07-06, 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. "CoRE Interfaces", Zach Shelby, Matthieu Vial, Michael Koster, 2015-07-06, This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. "Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2015-07-03, This document provides reference information for implementing a proxy that performs translation between the HTTP protocol and the CoAP protocol, focusing on the reverse proxy case. It describes how a HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to a HTTP response. Furthermore, it defines a template for URI mapping and provides a set of guidelines for HTTP to CoAP protocol translation and related proxy implementations. CBOR Object Signing and Encryption (cose) ----------------------------------------- "CBOR Encoded Message Syntax", Jim Schaad, 2015-07-05, Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies how to do signatures, message authentication codes and encryption using this data format. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 2015-02-20, This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", Tony Finch, Matthew Miller, Peter Saint-Andre, 2015-04-23, The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. "Updates to and Operational Guidance for the DANE Protocol", Viktor Dukhovni, Wesley Hardaker, 2015-07-01, This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. "SMTP security via opportunistic DANE TLS", Viktor Dukhovni, Wesley Hardaker, 2015-05-29, This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). "Using DANE to Associate OpenPGP public keys with email addresses", Paul Wouters, 2015-04-01, OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. This document specifies a method for publishing, locating and verifying OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via DNSSEC. DiffServ Applied to Real-time Transports (dart) ----------------------------------------------- "Differentiated Services (DiffServ) and Real-time Communication", David Black, Paul Jones, 2014-11-10, This memo describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. Dynamic Host Configuration (dhc) -------------------------------- "Access Network Identifier Option in DHCP", Shwetha Bhandari, Sri Gundavelli, Mark Grayson, Bernie Volz, Jouni Korhonen, 2015-07-05, This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. "Customizing DHCP Configuration on the Basis of Network Topology", Ted Lemon, Tomek Mrugalski, 2015-07-06, DHCP servers have evolved over the years to provide significant functionality beyond that which is described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and makes recommendations as to how they can be used. "Secure DHCPv6", Sheng Jiang, Sean Shen, Dacheng Zhang, Tatuya Jinmei, 2015-06-10, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not being secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism for communications between DHCPv6 clients and DHCPv6 servers. This document provides a DHCPv6 client/server authentication mechanism based on sender's public/private key pairs or certificates with associated private keys. The DHCPv6 message exchanges are protected by the signature option and the timestamp option newly defined in this document. "DHCPv6 Active Leasequery", Dushyant, Kim Kinnear, Deepak Kukrety, 2015-06-09, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol, and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC5460) by adding new options. "Active DHCPv4 Lease Query", Kim Kinnear, Mark Stapp, Bernie Volz, Neil Russell, 2015-06-10, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. In addition, continuous update of an external client with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 address binding information data via TCP. This document updates RFC6926, DHCPv4 Bulk Leasequery. "Dynamic Allocation of Shared IPv4 Addresses", Yong Cui, Qiong, Ian Farrer, Yiu Lee, Qi Sun, Mohamed Boucadair, 2015-05-28, This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, each client being differentiated by a unique set of transport layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included. Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized. "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Fernando Gont, Shucheng LIU, 2015-04-08, This document specifies a method for selecting IPv6 Interface Identifiers, to be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server side algorithm, that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6-variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration. "Privacy considerations for DHCP", Sheng Jiang, Suresh Krishnan, Tomek Mrugalski, 2015-02-09, DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. "Privacy considerations for DHCPv6", Suresh Krishnan, Tomek Mrugalski, Sheng Jiang, 2015-02-11, DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document discusses the various identifiers used by DHCPv6 and the potential privacy issues. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael Richardson, Sheng Jiang, Ted Lemon, 2015-07-06, The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be used separately or concurrently with the latter to obtain configuration parameters. This document updates the original DHCPv6 specification (RFC 3315) and incorporates RFC 3633, RFC 3736, RFC 7083, and RFC 7550. "Anonymity profile for DHCP clients", Christian Huitema, Tomek Mrugalski, Suresh Krishnan, 2015-06-30, Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. This draft updates RFC4361. DTLS In Constrained Environments (dice) --------------------------------------- "A TLS/DTLS Profile for the Internet of Things", Hannes Tschofenig, Thomas Fossati, 2015-06-11, A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensor or controls actuators for use in home automation, industrial control systems, smart cities and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram TLS (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in Internet of Things products that can easily be solved by using these well-researched and widely deployed Internet security protocols. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2015-07-06, In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. "Diameter AVP Level Security End-to-End Security: Scenarios and Requirements", Hannes Tschofenig, Jouni Korhonen, Glen Zorn, Kervin Pillay, 2015-06-17, This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. "Diameter Overload Indication Conveyance", Jouni Korhonen, Steve Donovan, Ben Campbell, Lionel Morand, 2015-02-04, This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC). "Diameter Congestion and Filter Attributes", Lyle Bertz, Serge Manning, Brent Hirschman, 2015-07-01, This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN and minimize Diameter filter administration. RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions and actions. It however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter- Rule are congested. Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) are not captured by Accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition. The optional attributes defined in this document are forward and backwards compatible with RFC 5777. "Diameter Overload Rate Control", Steve Donovan, Eric Noel, 2015-03-06, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. Requirements "Diameter Agent Overload", Steve Donovan, 2015-03-06, This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution. The extension addresses the handling of occurrences of overload of a Diameter agent, or more generally, a Diameter peer. Requirements "Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions", Cathy Zhou, Tom Taylor, Qiong, Mohamed Boucadair, 2015-06-24, During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. "Diameter Load Information Conveyance", Ben Campbell, Steve Donovan, Jean-Jacques Trottin, 2015-07-06, This document defines a mechanism for sharing of Diameter load information. RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. Domain-based Message Authentication, Reporting & Conformance (dmarc) -------------------------------------------------------------------- "Interoperability Issues Between DMARC and Indirect Email Flows", Franck Martin, Eliot Lear, Tim Draegen, Elizabeth Zwicky, 2015-06-09, DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Distributed Mobility Management (dmm) ------------------------------------- "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Vijay Devarapalli, 2015-04-22, Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). "On Demand Mobility Management", Alper Yegin, Kisuk Kweon, Jinsung Lee, Jungshin Park, Danny Moses, 2015-05-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, 2015-07-06, The specification as per this document supports the separation of the Control-Plane for mobility- and session management from the actual Data-Plane. The protocol semantics abstract from the actual details for the configuration of Data-Plane nodes and apply between a Client function, which is used by an application of the mobility Control- Plane, and an Agent function, which is associated with the configuration of Data-Plane nodes according to the policies issued by the mobility Control-Plane. The scope of the policies comprises forwarding rules and treatment of packets in terms of encapsulation, IP address re-writing and QoS. Additional protocol semantics are described to support the maintenance of the Data-Plane path. Domain Name System Operations (dnsop) ------------------------------------- "Initializing a DNS Resolver with Priming Queries", Peter Koch, M. Larson, 2015-03-09, This document describes the initial queries a DNS resolver is supposed to emit in order to initialize its cache with both a current NS RRSet for the root zone and the necessary address information. "DNSSEC Key Rollover Timing Considerations", Stephen Morris, Johan Ihren, John Dickinson, Matthijs Mekking, 2014-10-13, This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. "Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.", Mark Andrews, 2015-04-20, RFC6598 specified that: "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure." This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries accidently leaking to the global DNS infrastructure. "DNSSEC Roadblock Avoidance", Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy, 2015-07-01, This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. "The edns-tcp-keepalive EDNS0 Option", Paul Wouters, Joe Abley, Sara Dickinson, Ray Bellis, 2015-07-03, DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for fallback and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. "Chain Query requests in DNS", Paul Wouters, 2015-03-09, This document defines an EDNS0 extension that can be used by a security-aware validating Resolver configured as a Forwarder to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries lowers the latency. This extension requries the use of source IP verified transport such as TCP or UDP with DNS-COOKIES so it cannot be abused in amplification attacks. "DNS query name minimisation to improve privacy", Stephane Bortzmeyer, 2015-06-19, This document describes one of the techniques that could be used to improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. REMOVE BEFORE PUBLICATION Discussions of the document should take place on the DNSOP working group mailing list [dnsop]. "Client Subnet in DNS Queries", Carlo Contavalli, Wilmer van der Gaast, David Lawrence, Warren Kumari, 2015-07-06, This draft defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent response can be cached. IESG Note [RFC Editor: Please remove this note prior to publication ] This informational document describes an existing, implemented and deployed system. A subset of the operators using this is at http://www.afasterinternet.com/participants.htm . The authors believe that it is better to document this system (even if not everyone agrees with the concept) than leave it undocumented and proprietary. "Domain Name System (DNS) Cookies", Donald Eastlake, Mark Andrews, 2015-07-01, DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. "Decreasing Access Time to Root Servers by Running One on Loopback", Warren Kumari, Paul Hoffman, 2015-06-25, Some DNS recursive resolvers have longer-than-desired round trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. "DNS Transport over TCP - Implementation Requirements", John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, Duane Wessels, 2015-07-06, This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. "Definition and Use of DNSSEC Negative Trust Anchors", Paul Ebersman, Chris Griffiths, Warren Kumari, Jason Livingood, Ralf Weber, 2015-07-14, DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains. [RFC Editor: Please remove this before publication. This document is being stored in github at https://github.com/wkumari/draft-livingood- dnsop-negative-trust-anchors . Authors accept pull requests, and keep the latest (edit buffer) versions there, so commenters can follow along at home.] "DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara, 2015-06-22, The DNS is defined in literally dozens of different RFCs. The terminology used in 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. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2015-07-03, 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. ] "The .onion Special-Use Domain Name", Jacob Appelbaum, Alec Muffett, 2015-06-20, This document registers the ".onion" Special-Use Domain Name. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "On Interoperation of Labels Between mDNS and DNS", Andrew Sullivan, 2015-07-04, Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. "DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2015-03-09, The Domain Name System (DNS) was designed to efficiently return matching records 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. DNS PRIVate Exchange (dprive) ----------------------------- "DNS privacy considerations", Stephane Bortzmeyer, 2015-06-15, This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. "TLS for DNS: Initiation and Performance Considerations", Zi, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, Paul Hoffman, 2015-07-05, This document offers an approach to initiating TLS for DNS: use of a dedicated DNS-over-TLS port, and fallback to a mechanism for upgrading a DNS-over-TCP connection over the standard port (TCP/53) to a DNS-over-TLS connection. Encryption provided by TLS eliminates opportunities for eavesdropping on DNS queries in the network, such as discussed in RFC 7258. In addition it specifies two usage profiles for DNS-over-TLS. Finally, it provides advice on performance considerations to minimize overheads from using TCP and TLS with DNS, pertaining to both approaches. "DNS over DTLS (DNSoD)", Tirumaleswar Reddy, Dan Wing, Prashanth Patil, 2015-06-04, DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information which is valuable to protect. An active attacker can send bogus responses causing misdirection of the subsequent connection. To counter passive listening and active attacks, this document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As DNS needs to remain fast, this proposal also discusses mechanisms to reduce DTLS round trips and reduce DTLS handshake size. The proposed mechanism runs over the default DNS port and can also run over an alternate port. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Session Peering Provisioning (SPP) Protocol over SOAP", Kenneth Cartwright, Vikas Bhatia, Jean-Francois Mule, Alexander Mayrhofer, 2014-10-22, The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision session establishment data into Session Data Registries and SIP Service Provider data stores. To utilize this framework one needs a transport protocol. Given that Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the transport protocol for SPPF. The benefits include leveraging prevalent expertise, and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF based protocol. "Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright, Vikas Bhatia, Syed Ali, David Schwartz, 2015-03-25, This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session establishment. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Additional Data Related to an Emergency Call", Randall Gellens, Brian Rosen, Hannes Tschofenig, Roger Marshall, James Winterbottom, 2015-07-05, When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. "Next-Generation Pan-European eCall", Randall Gellens, Hannes Tschofenig, 2015-07-06, This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required in the very near future in European Union member states, and eCall (and eCall- compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. "Next-Generation Vehicle-Initiated Emergency Calls", Randall Gellens, Brian Rosen, Hannes Tschofenig, 2015-07-06, This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. Profiling and simplifications of the general emergency call mechanism, as described in [RFC6443] and [RFC6881], are possible due to the nature of the functionality that is provided in vehicles such as the usage of Global Satellite Navigation System (GNSS). 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), as described in [I-D.ietf-ecrit-ecall]. 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). "A Routing Request Extension for the HELD Protocol", James Winterbottom, Hannes Tschofenig, Laura Liess, 2015-04-05, In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. The general ECRIT calling models breakdown without publically accessible LoST servers. Sometimes location servers may have access to emergency routing information. This document defines an extension to the HELD protocol so a location request can include a request for routing information and allowing the subsequent location response to include routing information. Energy Management (eman) ------------------------ "Definition of Managed Objects for Battery Monitoring", Juergen Quittek, Rolf Winter, Thomas Dietz, 2015-04-17, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. "Energy Management (EMAN) Applicability Statement", Brad Schoening, Mouli Chandramouli, Bruce Nordman, 2015-05-12, The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. Extensible Provisioning Protocol Extensions (eppext) ---------------------------------------------------- "Key Relay Mapping for the Extensible Provisioning Protocol", M. Groeneweg, Antoin Verschuren, rikribbers, 2015-06-29, This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in [RFC5730]. This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)", James Gould, Wil Tan, Gavin Brown, 2015-03-31, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)", Francisco Obispo, 2015-01-05, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional features required to implement registrations of domain names in characters sets other than ASCII. "Mark and Signed Mark Objects Mapping", Gustavo Lozano, 2015-02-26, This document describes the format of a mark and a digitally signed mark, referred to as a signed mark and the Signed Mark Data (SMD) file as defined by the ICANN Trademark Clearinghouse. Global Access to the Internet for All (gaia) -------------------------------------------- "Alternative Network Deployments. Taxonomy, characterization, technologies and architectures", Jose Saldana, Andres Arcia-Moret, Bart Braem, Ermanno Pietrosemoli, Arjuna Sathiaseelan, Marco Zennaro, 2015-07-01, This document presents a taxonomy of "Alternative Network deployments", and a set of definitions and shared properties. It also discusses the technologies employed in these network deployments, and their differing architectural characteristics. The term "Alternative Network Deployments" includes a set of network access models that have emerged in the last decade with the aim of bringing Internet connectivity to people, using topological, architectural and business models different from the so-called "traditional" ones, where a company deploys or leases the network infrastructure for connecting the users, who pay a subscription fee to be connected and make use of it. Several initiatives throughout the world have built large scale alternative Networks, using predominantly wireless technologies (including long distance) due to the reduced cost of using the unlicensed spectrum. Wired technologies such as fiber are also used in some of these alternate networks. There are several types of alternate networks: community networks, which are self-organized and decentralized networks wholly owned by the community; networks owned by individuals who act as wireless internet service providers (WISPs); networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, and finally there are networks that provide connectivity by sharing wireless resources of the users. The emergence of these networks can be motivated by different causes such as the reluctance, or the impossibility, of network operators to provide wired and cellular infrastructures to rural/remote areas. In these cases, the networks have self sustainable business models that provide more localized communication services as well as Internet backhaul support through peering agreements with traditional network operators. Some other times, networks are built as a complement and an alternative to commercial Internet access provided by "traditional" network operators. The present classification considers different existing network models such as Community Networks, open wireless services, user- extensible services, traditional local Internet Service Providers (ISPs), new global ISPs, etc. Different criteria are used in order to build a classification as e.g., the ownership of the equipment, the way the network is organized, the participatory model, the extensibility, if they are driven by a community, a company or a local stakeholder (public or private), etc. According to the developed taxonomy, a characterization of each kind of network is presented in terms of specific network characteristics related to architecture, organization, etc. General Area (gen) ------------------ "Experiences from Cross-Area Work at the IETF", Jari Arkko, 2013-02-06, This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. "Intellectual Property Rights in IETF Technology", Scott Bradner, Jorge Contreras, 2013-10-11, The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. "Expectations of Implementers of IETF Protocols", Russ Housley, 2014-05-10, By choosing to implement an IETF protocol, one is expected to follow the specification, associated best current practices, and IANA registry practices. "IETF Anti-Harassment Procedures", Pete Resnick, Adrian Farrel, 2015-03-05, IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, social events, or on mailing lists. This document lays out procedures for managing and enforcing this policy. This document updates RFC 2418. "Tracking Reviews of Documents", Robert Sparks, Tero Kivinen, 2015-05-21, Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows. "Updating the Definition of Term for IAOC Members", Scott Bradner, 2015-05-28, The start and end dates specified in BCP 101 for terms of IAOC members has proven to be impractical. This memo updates BCP 101 to establish start and end dates for terms of IAOC members that will be more practical. In addition, this memo clarifies the term of the IAOC Chair. Global Routing Operations (grow) -------------------------------- "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 2015-07-04, This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen- scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service- affecting. BMP is not suitable for use as a routing protocol. "IRR & Routing Policy Configuration Considerations", Danny McPherson, Shane Amante, Eric Osterweil, Larry Blunk, Dave Mitchell, 2014-08-27, The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. "Internet Exchange BGP Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 2015-06-08, The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. "Impact of BGP filtering on Inter-Domain Routing Policies", Camilo Cardona, P. Francois, Paolo Lucente, 2015-06-09, This document describes how unexpected traffic flows can emerge across an autonomous system, as the result of other autonomous systems filtering, or restricting the propagation of more specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it. "The "import-via" and "export-via" attributes in RPSL Policy Specifications", Job Snijders, 2015-05-23, This document defines two attributes in the aut-num Class which can be used in RPSL policy specifications to publish desired routing policy regarding non-adjacent networks. "Problem Definition and Classification of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Danny McPherson, Eric Osterweil, Brian Dickson, 2015-07-05, A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date we have lacked a common definition of the term. In this document, we provide a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, we attempt to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. We aim to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Lars Eggert, 2015-06-30, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC5203. "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 2015-06-10, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu, 2015-06-23, This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Julien Laganier, 2015-06-10, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. "Host Mobility with the Host Identity Protocol", Thomas Henderson, Christian Vogt, Jari Arkko, 2015-01-12, This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 2015-01-22, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. "Host Multihoming with the Host Identity Protocol", Thomas Henderson, Christian Vogt, Jari Arkko, 2015-01-12, This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. "Host Identity Protocol Certificates", Tobias Heer, Samu Varjonen, 2015-06-29, 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) and Simple Public Key Infrastructure (SPKI) certificates. 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 extends [RFC7401]. Home Networking (homenet) ------------------------- "Home Networking Control Protocol", Markus Stenberg, Steven Barth, Pierre Pfister, 2015-07-05, This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. "Outsourcing Home Network Authoritative Naming Service", Daniel Migault, Ralf Weber, Ray Hunter, Chris Griffiths, Wouter Cloetens, 2015-07-02, RFC7368 'IPv6 Home Networking Architecture Principles' section 3.7 describes architecture principles related to naming and service discovery in residential home networks. Customer Edge Routers and other Customer Premises Equipment (CPEs) are designed to provide IP connectivity to home networks. Most CPEs assign IP addresses to the nodes of the home network which makes them good candidates for hosting the naming service. IPv6 provides global connectivity, and nodes from the home network will be reachable from the global Internet. As a result, the naming service is expected to be exposed on the Internet. However, CPEs have not been designed to host such a naming service exposed on the Internet. Running a naming service visible on the Internet may expose the CPEs to resource exhaustion and other attacks, which could make the home network unreachable, and most probably would also affect the internal communications of the home network. In addition, regular end users may not understand, or possess the necessary skills to be able to perform, DNSSEC management and configuration. Misconfiguration may also result in naming service disruption, thus these end users may prefer to rely on third party name service providers. This document describes a homenet naming architecture, where the CPEs manage the DNS zones associated with its own home network, and outsource elements of the naming service (possibly including DNSSEC management) to a third party running on the Internet. "DHCP Options for Homenet Naming Architecture", Daniel Migault, Wouter Cloetens, Chris Griffiths, Ralf Weber, 2015-05-19, CPEs are usually constraint devices with reduced network and CPU capacities. As such, a CPE hosting on the Internet the authoritative naming service for its home network may become vulnerable to resource exhaustion attacks. One way to avoid exposing CPE is to outsource the authoritative service to a third party. This third party can be the ISP or any other independent third party. Outsourcing the authoritative naming service to a third party requires setting up an architecture which may be unappropriated for most end users. To leverage this issue, this document proposes DHCP Options so any agnostic CPE can automatically proceed to the appropriated configuration and outsource the authoritative naming service for the home network. This document shows that in most cases, these DHCP Options make outsourcing to a third party (be it the ISP or any ISP independent service provider) transparent for the end user. "Distributed Prefix Assignment Algorithm", Pierre Pfister, Benjamin Paterson, Jari Arkko, 2015-06-15, This document specifies a distributed algorithm for automatic prefix assignment. Thus it provides an alternative to manual or centralized prefix and address assignment techniques. Given a set of delegated prefixes, it ensures that at most one prefix is assigned from each delegated prefix to each link. Nodes may assign available prefixes to the links they are directly connected to, or for other private purposes. The algorithm eventually converges and ensures that all assigned prefixes do not overlap. "Distributed Node Consensus Protocol", Markus Stenberg, Steven Barth, 2015-07-02, This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. "Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes", Markus Stenberg, 2015-03-05, This document describes how a proxy functioning between Unicast DNS- Based Service Discovery and Multicast DNS can be automatically configured using an arbitrary network-level state sharing mechanism. Hypertext Transfer Protocol Authentication (httpauth) ----------------------------------------------------- "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, lef, Yuichi Ioku, 2015-07-06, This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. "HTTP Authentication Extensions for Interactive Clients", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, lef, Yuichi Ioku, 2015-07-06, This document specifies a few extensions of HTTP authentication framework for interactive clients. Recently, fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. "Salted Challenge Response (SCRAM) HTTP Authentication Mechanism", Alexey Melnikov, 2015-06-18, The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses security concerns with HTTP Digest and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for HTTP authentication. "The 'Basic' HTTP Authentication Scheme", Julian Reschke, 2015-02-28, This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. "HTTP Digest Access Authentication", Rifaat Shekh-Yusef, David Ahrens, Sophie Bremer, 2015-04-23, HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPAuth working group mailing list (http-auth@ietf.org), which is archived at [1]. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, lef, Yuichi Ioku, 2015-07-06, This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Hypertext Transfer Protocol (httpbis) ------------------------------------- "HTTP Alternative Services", mnot, Patrick McManus, Julian Reschke, 2015-05-15, This document specifies "alternative services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. "Opportunistic Security for HTTP", mnot, Martin Thomson, 2015-06-15, This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. "The ALPN HTTP Header Field", Andrew Hutton, Justin Uberti, Martin Thomson, 2015-06-11, This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field. "The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy- Authentication-Info Response Header Fields", Julian Reschke, 2015-04-07, This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted. "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding", Julian Reschke, 2015-05-30, In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages. Content codings can be used in request messages as well, however discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate that content codings are supported in requests. "An HTTP Status Code to Report Legal Obstacles", Tim Bray, 2015-06-28, This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at [1]. Working Group information can be found at [2] and [3]; source code and issues list for this draft can be found at [4]. BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "Compression Extensions for WebSocket", Takeshi Yoshino, 2015-06-23, This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying parameter negotiation and payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. Please send feedback to the hybi@ietf.org mailing list. Interface to the Routing System (i2rs) -------------------------------------- "An Architecture for the Interface to the Routing System", Alia Atlas, Joel Halpern, Susan Hares, David Ward, Tom Nadeau, 2015-03-06, This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). "Interface to the Routing System Problem Statement", Alia Atlas, Tom Nadeau, David Ward, 2015-01-07, As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). "Routing Information Base Info Model", Nitin Bahadur, Ron Folkes, Sriganesh Kini, Jan Medved, 2015-03-08, Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. "I2RS requirements for netmod/netconf", Jeffrey Haas, 2015-03-08, This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. "BGP Model for Service Provider Networks", Anees Shaikh, Rob Shakir, Keyur Patel, Susan Hares, Kevin D'Souza, Deepak Bansal, Alex Clemm, Alex, Mahesh Jethanandani, Xufeng Liu, 2015-06-14, 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. "Summary of I2RS Use Case Requirements", Susan Hares, Mach Chen, 2015-05-19, The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", Joe Clarke, Gonzalo Salgueiro, Carlos Pignataro, 2015-05-27, This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. "Yang Data Model for BGP Protocol", Alex, Keyur Patel, Alex Clemm, Susan Hares, Mahesh Jethanandani, Xufeng Liu, 2015-01-29, This document defines a YANG data model that can be used to configure and manage BGP. "A YANG Data Model for Layer 1 Network Topology", Xian Zhang, Baoquan Rao, Xufeng Liu, 2015-03-08, This draft describes a YANG data model to manipulate the topologies of a layer 1 network. It is independent of data plan technologies and control plane protocols. It can be augmented to include technology-specific data, such as for Optical Transport Networks (OTN). "Requirements for Subscription to YANG Datastores", Eric Voit, Alex Clemm, Alberto Prieto, 2015-03-26, This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. "Identifier Management for I2RS Protocol", Ran Chen, Frank Feng, 2015-03-22, An I2RS Agent may communicate with multiple clients. Two (or more) client may attempt to manipulate the same piece of data on the I2RS Agent. In order to solve this collision, the proposal is to have a simple priority associated with each I2RS Client. In addition, if the hold timer for an I2RS session expires, the I2RS Agent should delete the I2RS data associated with the I2RS Client. In order to delete the related I2RS data correctly, it is important to identify the client on the I2RS Agent. This document describes how to deploy identifier and priority associated with each I2RS Client based on [I-D.ietf-i2rs-architecture]. "A YANG Data Model for Routing Information Base (RIB)", Lixing Wang, Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh Kini, Nitin Bahadur, 2015-04-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, 2015-06-05, This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. "A YANG Data Model for Layer-2 Network Topologies", Jie Dong, Xiugang Wei, 2015-07-06, This document defines a YANG data model for Layer 2 network topologies. "A YANG Data Model for Layer 3 Topologies", Alex Clemm, Jan Medved, Robert Varga, Tony Tkacik, Xufeng Liu, Igor Bryskin, Aihua Guo, Hariharan Ananthakrishnan, Nitin Bahadur, Vishnu Pavan Beeram, 2015-06-08, This document defines a YANG data model for layer 3 network topologies. "I2RS Ephemeral State Requirements", Jeffrey Haas, Susan Hares, 2015-06-23, This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Internet Architecture Board (iab) --------------------------------- "Technical Considerations for Internet Service Blocking and Filtering", Richard Barnes, Alissa Cooper, Olaf Kolkman, Dave Thaler, 2015-07-06, The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering," the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. In general, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. "DNS Root Name Service Protocol and Deployment Requirements", Marc Blanchet, Lars-Johan Liman, 2015-02-14, The DNS Root Name service is a critical part of the Internet architecture. The protocol and deployment requirements expected to be implemented for the DNS root name service are defined in this document. Operational requirements are out of scope. "Assigning Digital Object Identifiers to RFCs", John Levine, 2015-06-11, The Digital Object Identifier (DOI) is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion. We describe the way that DOIs are assigned to past and future RFCs. "Report from the Strengthening the Internet (STRINT) workshop", Stephen Farrell, Rigo Wenning, Bert Bos, Marc Blanchet, Hannes Tschofenig, 2015-05-28, The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, which it is believed could be implemented and which could help strengthen the Internet. This is the report of that workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", Richard Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie, Brian Trammell, Christian Huitema, Daniel Borkmann, 2015-05-28, Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. "The 'XML2RFC' version 2 Vocabulary", Julian Reschke, 2015-06-09, This document defines the 'XML2RFC' version 2 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. Version 2 represents the current state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the XML2RFC mailing list (xml2rfc@ietf.org), which has its home page at . "Digital Preservation Considerations for the RFC Series", Heather Flanagan, 2015-01-24, The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs, and the tools required to view or re-create RFCs as necessary. This document also highlights where gaps are in the current process, and where compromises are suggested to balance cost with ideal best practice. "Confidentiality in the Face of Pervasive Surveillance", Ted Hardie, 2015-06-02, The IAB has published [I-D.iab-privsec-confidentiality-threat] 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. "IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report", Brian Trammell, Mirja Kuehlewind, 2015-06-03, The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop, provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. Planning for the IANA/NTIA Transition (ianaplan) ------------------------------------------------ "Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries", Eliot Lear, Russ Housley, 2015-01-06, The U.S. NTIA has solicited a request from ICANN to propose how the NTIA should end its oversight of the IANA functions. After broad consultations, ICANN has in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for thre three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It is meant to be included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. Information-Centric Networking (icnrg) -------------------------------------- "Information-centric Networking: Evaluation Methodology", Kostas Pentikousis, Borje Ohlman, Elwyn Davies, Spiros Spirou, Gennaro Boggia, 2015-07-06, This document surveys the evaluation tools currently available to researchers in the information-centric networking (ICN) area and provides suggestions regarding methodology and metrics. Finally, this document sheds some light on the impact of ICN on network security. "Adaptive Video Streaming over ICN", Stefan Lederer, cedric.westphal@huawei.com, Christopher Mueller, Andrea Detti, Daniel Corujo, Christian Timmerer, Daniel Posch, aytav.azgin, Sucheng Liu, 2015-02-25, This document considers the consequences of moving the underlying network architecture to an Information-Centric Network (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented, covering a wide range of scenarios: we look at how to evolve DASH to work over ICN, and leverage the recent ISO/IEC MPEG Dynamic Adaptive Streaming over HTTP (DASH) standard; we consider layered encoding over ICN; P2P mechanisms introduce distinct requirements for video and we look at how to adapt PPSP for ICN; IPTV adds delay constraints, and this will create more stringent requirements over ICN as well. As part of the discussion on video, we discuss DRMs in ICN. Finally, in addition to consider how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN specific video streaming mechanisms. "ICN Research Challenges", Dirk Kutscher, Suyong Eum, Kostas Pentikousis, Ioannis Psaras, Daniel Corujo, Damien Saucez, Thomas Schmidt, Matthias Waehlisch, 2015-02-01, This memo describes research challenges for Information-Centric Networking. Information-Centric Networking is an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling in-network caching and replication. Challenges include naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. "CCNx Semantics", marc.mosko@parc.com, 2015-06-29, This document describes the core concepts of the CCNx architecture and presents a minimum network protocol based on two messages: Interest and Content Object. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a Control message called an InterestReturn, whereby one system can return an Interest message to the previous hop due to an error condition. It indicates to the previous hop that the current system will not respond to the Interest. "CCNx Messages in TLV Format", marc.mosko@parc.com, 2015-06-29, This document specifies the encoding of CCNx messages using a TLV Packet specification. CCNx messages follow the CCNx Semantics specification. This document defines the TLV types used by each message element and the encoding of each value. Inter-Domain Routing (idr) -------------------------- "Analysis of Existing work for I2NSF", Susan Hares, Keyur Patel, 2015-07-06, This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 2014-10-24, In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 2015-06-07, 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, 2015-01-13, 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 extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. "Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen, 2015-03-07, 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. "Assigned BGP extended communities", Bruno Decraene, P. Francois, 2015-01-13, 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. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, 2015-07-02, This document proposes a solution for BGP route reflectors to facilitate the application of closest exit point policy (hot potato routing) without requiring further state or any new features to be placed on the RR clients. This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration for hot potato routing. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per neighbour. "Extended Message support for BGP", Keyur Patel, David Ward, Randy Bush, 2015-07-06, 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 [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 2015-06-23, 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. "Revised Error Handling for BGP UPDATE Messages", Enke Chen, John Scudder, Pradosh Mohapatra, Keyur Patel, 2015-04-22, According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable, because a session reset would impact not only routes with the offending attribute, but also other, valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701 and 6368. "BGP Custom Decision Process", Alvaro Retana, Russ White, 2015-04-20, The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. "Codification of AS 0 processing.", Warren Kumari, Randy Bush, Heather Schiller, Keyur Patel, 2012-08-26, This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN and AS_PATH / AS4_PATH BGP attribute. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 2015-04-27, 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. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. "Automatic Route Target Filtering for legacy PEs", Pradosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 2015-05-28, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. "Carrying next-hop cost information in BGP", Ilya Varlashkin, Robert Raszuk, Keyur Patel, Manish Bhardwaj, Serpil Bayraktar, 2015-05-16, BGPLS provides a mechanism by which Link state and traffic engineering information can be collected from internal networks and shared with external network routers using BGP. BGPLS defines a new Address Family to exchange this information using BGP. BGP Optimal Route Reflection (ORR) provides a mechanism for a centralized BGP Route Reflector to acheive requirements of a Hot Potato Routing as described in Section 11 of [RFC4456]. Optimal Route Reflection requires BGP ORR to overwrite the default IGP location placement of the route reflector; which is used for determining cost to the nexthop contained in the path. This draft augments BGPLS and defines a new extensions to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. "Internet Exchange BGP Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 2015-06-08, This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. "BGP Remote-Next-Hop", Gunter Van de Velde, Keyur Patel, Dhananjaya Rao, Robert Raszuk, Randy Bush, 2015-03-09, The BGP Remote-Next-Hop attribute is an optional transitive attribute intended to facilitate automatic tunnelling across an AS for an NLRI in a given address family. The attribute carries one or more tunnel end-points and associated tunnel encapsulation information for a NLRI. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray, 2015-06-04, In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). "Inter-domain SLA Exchange", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 2015-04-26, Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling which can help to simplify some of the complexities. This document defines an optional transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks. Though the use case with the proposed BGP attribute is explicitly defined in this document, purpose of this attribute is not limited to this use case only. "BGP Flow-Spec Redirect to IP Action", Jim Uttaro, Jeffrey Haas, Matthieu Texier, Andy, Saikat Ray, Adam Simpson, Wim Henderickx, 2015-02-05, Flow-spec 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 [RFC 5575] defines a redirect-to-VRF action for policy-based forwarding but this mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities. "BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics", Qin Wu, Stefano Previdi, Hannes Gredler, Saikat Ray, Jeff Tantsura, 2015-01-04, In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into Traffic Engineering Database(TED) and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ). "Distribution of MPLS Traffic Engineering (TE) LSP State using BGP", Jie Dong, Mach Chen, Hannes Gredler, Stefano Previdi, Jeff Tantsura, 2015-05-07, This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement and network visualization. "Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute", Wesley George, Shane Amante, 2015-07-06, This draft discusses some existing commonly-used BGP mechanisms for ASN migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. "Clarification of the Flowspec Redirect Extended Community", Jeffrey Haas, 2015-04-11, This document updates RFC 5575 (Dissemination of Flow Specification Rules) to clarify the formatting of the the BGP Flowspec Redirect Extended Community. "Inter Domain considerations for Constrained Route distribution", Stephane Litkowski, Jeffrey Haas, Keyur Patel, 2015-03-05, [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). [RFC4684] addresses both intra domain and inter domain distributions. Based on operational deployments, the current distribution model defined in [RFC4684] may cause some issue in specific scenarios. This document refines the route distribution rules for inter domain NLRIs in order to address these specific scenarios. "BGP Link-State Information Distribution Implementation Report", Hannes Gredler, Balaji Rajagopalan, Chris Bowers, Saikat Ray, Manish Bhardwaj, 2015-05-01, This document is an implementation report for the BGP Link-State Information Distribution protocol. The editors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Jie Dong, Mach Chen, Robert Raszuk, 2015-06-25, 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 build 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, 2015-06-29, BGP routes sometimes carry an "Extended Communities" path attribute. An Extended Communities path attribute can contain one or more "Route Targets" (RTs). By means of a procedure known as "RT Constrained Distribution" (RTC), a BGP speaker can send BGP UPDATE messages that express its interest in a particular set of RTs. Generally, RTC has been applied only to address families whose routes always carry RTs. When RTC is applied to such an address family, a BGP speaker expressing its interest in a particular set of RTs is indicating that it wants to receive all and only the routes of that address family that have at least one of the RTs of interest. However, there are scenarios in which the originator of a route chooses not to include any RTs at all, assuming that the distribution of a route with no RTs at all will be unaffected by RTC. This has led to interoperability problems in the field, where the originator of a route assumes that RTC will not affect the distribution of the route, but intermediate BGP speakers refuse to distribute that route because it does not carry any RT of interest. The purpose of this document is to clarify the effect of the RTC mechanism on routes that do not have any RTs. "Performance-based BGP Routing Mechanism", Xiaohu Xu, Mohamed Boucadair, Christian Jacquenet, Ning So, Yimin Shen, Uma Chunduri, Hui Ni, Fan Yongbing, Luis Contreras, 2015-02-26, The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. "Advertisement of Multiple Paths in BGP: Implementation Report", Alvaro Retana, 2015-02-02, This document reports the results of an ADD-PATH implementation survey. The survey had 22 questions about implementations' support for advertising multiple paths in BGP. After a brief summary of the results, each response is listed. This document contains responses from six implementers who completed the survey. The editor did not use external means to verify the accuracy of the information submitted by the respondents. The respondents are considered experts on the products they reported on. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 2015-02-02, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Thomas King, 2015-03-24, When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses BGP next hop cost to signal the state of the data link to the route server(s). "Dissemination of Flow Specification Rules for L2 VPN", Hao Weiguo, LQD, Stephane Litkowski, Shunwan Zhuang, 2015-05-08, 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. "Registered Wide BGP Community Values", Robert Raszuk, Jeffrey Haas, 2015-03-07, 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. "Path validation toward BGP next-hop with AUTO-BFD", Jerome Durand, David Freedman, 2015-03-09, This document describes a solution called AUTO-BFD, that automatically initiates BFD sessions for BGP next-hops. This makes it possible to avoid blackholing scenarios when a BGP peer is not the BGP next-hop, especially on Internet eXchange Points (IXPs) when BGP Route-Servers are deployed. When they are configured with this mechanism, routers can automatically try to establish a new adjacency for every new BGP next-hop. BGP routes are then checked against the state of the BFD session for the corresponding next-hop. Foreword A placeholder to list general observations about this document. "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi Sriram, Doug Montgomery, Brian Dickson, 2015-07-05, In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don't offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed. "Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang, Qin Wu, Jeff Tantsura, 2015-06-16, As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE. "Segment Routing Egress Peer Engineering BGP-LS Extensions", Stefano Previdi, Clarence Filsfils, Saikat Ray, Keyur Patel, Jie Dong, Mach Chen, 2015-06-17, Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP egress point topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient Egress Point Engineering policies and strategies. "Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen, 2015-06-25, Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. "Registered Wide BGP Community Values", Robert Raszuk, Jeffrey Haas, 2015-06-25, Communicating various routing policies via route tagging plays an important role in external BGP peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush, Jeffrey Haas, John Scudder, Arnold Nipper, Thomas King, 2015-07-06, When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses BGP next hop cost to signal the state of the data link to the route server(s). "BGP Model for Service Provider Networks", Anees Shaikh, Rob Shakir, Keyur Patel, Susan Hares, Kevin D'Souza, Deepak Bansal, Alex Clemm, Alex, Mahesh Jethanandani, Xufeng Liu, 2015-07-06, This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, James Polk, Gonzalo Salgueiro, Chris Pearce, 2015-03-06, This document describes an end-to-end Session Identifier for use in IP-based multimedia communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. This document also describes a backwards compatibility mechanism for an existing (RFC 7329) session identifier implementation that is sufficiently different from the procedures defined in this document. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, 2015-01-21, SIP networks use signalling monitoring tools to diagnose user reported problem 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 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 client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. "Marking SIP Messages to be Logged", Peter Dawes, 2015-02-27, 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) ------------------------------------- "IPv6 Support for Generic Routing Encapsulation (GRE)", Carlos Pignataro, Ron Bonica, Suresh Krishnan, 2015-06-25, Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. It updates the GRE specification, RFC 2784. IP Performance Metrics (ippm) ----------------------------- "Model Based Metrics for Bulk Transport Capacity", Matt Mathis, Al Morton, 2015-07-06, We introduce a new class of Model Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Bulk Transport Performance target 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 any path traversing it from meeting the specified Target Transport Performance. The IP diagnostic tests consist of precomputed traffic patterns and statistical criteria for evaluating packet delivery. The traffic patterns are precomputed to mimic TCP or other transport protocol over a long path but are constructed in such a way that they are independent of the actual details of the subpath under test, end systems or applications. Likewise the success criteria depends on the packet delivery statistics of the subpath, as evaluated against a protocol model applied to the Target Transport Performance. The success criteria also does not depend on the details of the subpath, end systems or application. This makes the measurements open loop, eliminating most of the difficulties encountered by traditional bulk transport metrics. Model based metrics exhibit several important new properties not present in other Bulk 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 results from multiple Measurement Points. This document does not define IP diagnostic tests directly, but provides a framework for designing suites of IP diagnostics tests that are tailored to confirming that infrastructure can meet a predetermined Target Transport Performance. "IKEv2-derived Shared Secret Key for O/TWAMP", Kostas Pentikousis, Emma Zhang, Yang Cui, 2015-05-29, The One-way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/TWAMP can support certificate-based key exchange, which would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management. "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip Eardley, Al Morton, Aamer Akhter, 2015-07-06, This document defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. "A One-Way Delay Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 2015-06-22, This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete. "A One-Way Loss Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 2015-06-22, This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete. "UDP Checksum Complement in OWAMP and TWAMP", Tal Mizrahi, 2015-03-09, The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. "Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP)", Jonas Hedin, Greg Mirsky, Steve Baillargeon, 2015-05-20, This document describes an OPTIONAL extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", Nalini Elkins, Rob, Michael Ackermann, 2015-06-11, To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. "Active and Passive Metrics and Methods (and everything in-between, or Hybrid)", Al Morton, 2015-06-30, This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as Active or Passive. Some methods may use a subset of both active and passive attributes, and we refer to these as Hybrid Methods. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "The NULL Authentication Method in IKEv2 Protocol", Valery Smyslov, Paul Wouters, 2015-06-03, This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. "Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks", Yoav Nir, Valery Smyslov, 2015-07-04, This document recommends implementation and configuration best practices for Internet-connected IPsec Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. "ChaCha20, Poly1305 and their use in IKE & IPsec", Yoav Nir, 2015-07-09, This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Extended Sequence number TLV", Uma Chunduri, Wenhu Lu, Albert Tian, Naiming Shen, 2015-04-22, This document defines Extended Sequence number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. "IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, Wenson Wu, 2015-06-16, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC5305) such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT)", Zhenbin Li, Nan Wu, Quintin Zhao, Alia Atlas, Chris Bowers, Jeff Tantsura, 2015-01-16, This document describes necessary extensions to IS-IS to support the distributed computation of Maximally Redundant Trees (MRT). Some example uses of the MRTs 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. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, Jeff Tantsura, 2015-06-30, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing. "Advertising S-BFD Discriminators in IS-IS", Les Ginsberg, Nobo Akiya, Mach Chen, 2015-03-01, This document defines a means of advertising one or more S-BFD Discriminators using the IS-IS Router Capability TLV. "IS-IS Prefix Attributes for Extended IP and IPv6 Reachability", Les Ginsberg, Bruno Decraene, Clarence Filsfils, Stephane Litkowski, Stefano Previdi, 2015-03-02, This document introduces new sub-TLVs to support advertisement of prefix attribute flags and the source router id of the router which originated a prefix advertisement. "IS-IS Route Preference for Extended IP and IPv6 Reachability", Les Ginsberg, Stephane Litkowski, Stefano Previdi, 2015-03-30, Existing specifications as regards route preference are not explicit when applied to IPv4/IPv6 Extended Reachability Type/Length/Value (TLVs). There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs). This document addresses these issues. "YANG Data Model for ISIS protocol", Stephane Litkowski, Derek Yeung, Acee Lindem, Jeffrey Zhang, Ladislav Lhotka, 2015-07-03, This document defines a YANG data model that can be used to configure and manage ISIS protocol on network elements. It also defined an extension module for segment routing configuration and operation. "IS-IS Path Computation and Reservation", Janos Farkas, Nigel Bragg, Paul Unbehagen, Glenn Parsons, Peter Ashwood-Smith, Chris Bowers, 2015-03-09, IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. "Advertising Per-node Admin Tags in IS-IS", P. Sarkar, Hannes Gredler, Shraddha Hegde, Stephane Litkowski, Bruno Decraene, Zhenbin Li, Ebben Aries, Rafael Rodriguez, Harish Raghuveer, 2015-06-01, This document describes an extension to IS-IS protocol [ISO10589], [RFC1195] to add an optional operational capability, that allows tagging and grouping of the nodes in an IS-IS domain. This allows simple management and easy control over route and path selection, based on local configured policies. This document describes the protocol extensions to disseminate per- node administrative tags in IS-IS protocols. "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT)", Zhenbin Li, Nan Wu, Quintin Zhao, Alia Atlas, Chris Bowers, Jeff Tantsura, 2015-02-11, This document describes necessary extensions to IS-IS to support the distributed computation of Maximally Redundant Trees (MRT). Some example uses of the MRTs 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. "IS-IS Path Computation and Reservation", Janos Farkas, Nigel Bragg, Paul Unbehagen, Glenn Parsons, Peter Ashwood-Smith, Chris Bowers, 2015-07-06, IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. "IS-IS Prefix Attributes for Extended IP and IPv6 Reachability", Les Ginsberg, Bruno Decraene, Clarence Filsfils, Stephane Litkowski, Stefano Previdi, Xiaohu Xu, Uma Chunduri, 2015-06-20, This document introduces new sub-TLVs to support advertisement of prefix attribute flags and the source router ID of the router which originated a prefix advertisement. "Signaling Entropy Label Capability Using IS-IS", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2015-05-20, Multi Protocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated that it can process ELs for that tunnel. This draft defines a mechanism to signal that capability using IS-IS. This mechanism is useful when the label advertisement is also done via IS-IS. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Web Key (JWK) Thumbprint", Michael Jones, Nat Sakimura, 2015-07-09, This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "Namespace Considerations and Registries for GSS-API Extensions", Nicolas Williams, Alexey Melnikov, 2015-01-13, This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. "A set of SASL Mechanisms for OAuth", William Mills, Tim Showalter, Hannes Tschofenig, 2015-05-29, OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. "AES Encryption with HMAC-SHA2 for Kerberos 5", Michael Jenkins, Michael Peck, Kelley Burgin, 2015-02-10, This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", Shawn Emery, Nicolas Williams, 2015-05-25, This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. "Generic Security Service API Version 2: Java Bindings Update", Mayank Upadhyay, Seema Malkani, Wang Weijun, 2015-02-05, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The 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). "Kerberos Authorization Data Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, Thomas Hardjono, 2015-06-25, This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension", Michiko Short, Seth Moore, Paul Miller, 2015-03-06, 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 which 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, 2015-02-17, This document proposes 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 the application services can use it as an input into policy decisions. "PKINIT Algorithm Agility", Love Astrand, Larry Zhu, Margaret Wasserman, William Mills, 2015-04-02, This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer Schatzmayr, Wim Henderickx, 2015-07-06, This document describes a simple L2 Ethernet over IPv6 tunnel encapsulation with mandatory 64-bit cookie for connecting L2 Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on L2TPv3 over IP. "Advertising S-BFD Discriminators in L2TPv3", Vengada Govindan, Carlos Pignataro, 2015-03-05, This document defines a new AVP for advertising one or more S-BFD Discriminators using the L2TPv3 Control Protocol AVP. "A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing Liu, Giles Heron, 2015-07-06, This document defines a YANG data model for the configuration and management of Keyed IPv6 tunnels. The data model includes configuration data and state data. Due to the stateless nature of keyed IPv6 tunnels, a model for NETCONF notifications is not necessary. L3VPN Service Model (l3sm) --------------------------- "YANG Data Model for L3VPN service delivery", Stephane Litkowski, Rob Shakir, Luis Tomotaki, Kevin D'Souza, 2015-07-02, 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. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP EID Block", Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller, 2015-05-19, This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, 2015-04-17, This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. "LISP Threats Analysis", Damien Saucez, Luigi Iannone, Olivier Bonaventure, 2015-03-05, This document proposes a threat analysis of the Locator/Identifier Separation Protocol (LISP). "LISP Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job Snijders, 2015-06-12, 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, 2015-04-15, This draft 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, 2015-07-03, This document proposes a framework for the management of the LISP EID Prefix. The framework described relies on hierarchical distribution of the address space, granting temporary usage of sub-prefixes of such space to requesting organizations. "LISP Impact", Damien Saucez, Luigi Iannone, Florin Coras, 2015-06-10, The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the Internet in general and the end-user in particular. "LISP Data-Plane Confidentiality", Dino Farinacci, Brian Weis, 2015-05-01, 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. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- "A framework for Large-Scale Measurement of Broadband Performance (LMAP)", Philip Eardley, Al Morton, Marcelo Bagnulo, Trevor Burbridge, Paul Aitken, Aamer Akhter, 2015-04-29, Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance). "Information Model for Large-Scale Measurement Platforms (LMAP)", Trevor Burbridge, Philip Eardley, Marcelo Bagnulo, Jürgen Schönwälder, 2015-07-03, This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. "A YANG Data Model for LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-07-03, This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. "Using RESTCONF with LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-07-04, This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Minimal IKEv2", Tero Kivinen, 2015-03-06, This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document describes mainly shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 7296, but provides more compact description of the minimal version of the protocol. If this document and RFC 7296 conflicts then RFC 7296 is the authoritative description. "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keranen, 2015-04-30, This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. "Energy Efficient Implementation of IETF Constrained Protocol Suite", Zhen Cao, Carles Gomez, Matthias Kovatsch, Hui Tian, Xuan He, 2015-05-19, This document summarizes the problems and current practices of energy efficient protocol implementation on constrained devices, mostly about how to make the protocols within IETF scope behave energy friendly. This document also summarizes the impact of link layer protocol power saving behaviors to the upper layer protocols, so that they can coordinately make the system energy efficient. "CoAP Implementation Guidance", Matthias Kovatsch, Olaf Bergmann, Carsten Bormann, 2015-07-06, The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks such as sensor nodes in a low-power lossy network (LLN). Yet to implement this Internet protocol on Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of ROM) also lightweight implementation techniques are necessary. This document provides lessons learned from implementing CoAP for tiny, battery-operated networked embedded systems. In particular, it provides guidance on correct implementation of the CoAP specification RFC 7252, memory optimizations, and customized protocol parameters. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Bo Berry, Shawn Jury, Darryl Satterwhite, Rick Taylor, 2015-07-06, 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 (AODVv2) Routing", Charles Perkins, Stan Ratliff, John Dowdell, Lotte Steenbrink, Victoria Mercieca, 2015-07-06, The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. "Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Christopher Dearlove, Thomas Clausen, 2015-07-06, This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFC 7188 and [tlv-naming] by modifying and extending TLV registries and descriptions. "Packet Sequence Number based directional airtime metric for OLSRv2", Henning Rogge, Emmanuel Baccelli, 2015-04-21, This document specifies an directional airtime link metric for usage in OLSRv2. "Snapshot of OLSRv2-Routed MANET Management", Thomas Clausen, Ulrich Herberg, 2014-09-15, This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET Neighborhood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single configuration parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols. "Identity-Based Signatures for MANET Routing Protocols", Christopher Dearlove, 2014-09-04, This document updates RFC7182, which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in RFC5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in RFC6507. "Definition of Managed Objects for the Neighborhood Discovery Protocol", Ulrich Herberg, Robert Cole, Ian Chakeres, Thomas Clausen, 2015-03-03, This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. "Security Threats for Simplified Multicast Forwarding (SMF)", Jiazi Yi, Thomas Clausen, Ulrich Herberg, 2015-03-23, This document analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. "Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Jiazi Yi, Benoit Parrein, 2015-07-02, 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. "TLV Naming in the MANET Generalized Packet/Message Format", Christopher Dearlove, Thomas Clausen, 2015-06-24, This document reorganizes the naming of already allocated TLV (type- length-value) types and type extensions in the Mobile Ad hoc NETwork (MANET) registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444. "Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Thomas Clausen, Ulrich Herberg, Jiazi Yi, 2015-02-12, 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 RFC5444 Generalized Packet/ Message Format", Thomas Clausen, Christopher Dearlove, Ulrich Herberg, Henning Rogge, 2015-06-23, This document updates the generalized MANET packet/message format, specified in RFC5444, by providing prescriptive guidelines for how protocols can use that packet/message format. In particular, these mandatory guidelines prohibit a number of uses of RFC5444 that have been suggested in various proposals, and which would have lead to interoperability problems, to impediment of protocol extension development, and to inability to use generic RFC5444 parsers. MBONE Deployment (mboned) ------------------------- "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed Boucadair, Stig Venaas, Qiong, 2015-03-03, Each IPTV operator has their own arrangements for pre-provisioning program information including addresses of the multicast groups corresponding to broadcast programs on the subscriber receiver. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines what has to be done to allow the receiver to acquire multicast address information in the version it supports in such scenarios. Multiple Interfaces (mif) ------------------------- "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 2015-03-06, Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose the fastest interface with an automatic fallback. "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", Jouni Korhonen, Suresh Krishnan, Sri Gundavelli, 2015-02-28, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. One part of the solution requires associating configuration information with provisioning domains. This document details how configuration information provided through IPv6 Neighbor Discovery Protocol can be associated with provisioning domains. "Support for multiple provisioning domains in DHCPv6", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, 2015-03-04, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. One part of the solution requires associating configuration information with provisioning domains. This document details how configuration information provided through DHCPv6 can be associated with provisioning domains. "Identification of provisioning domains", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, Sri Gundavelli, 2015-02-28, The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "The Incident Object Description Exchange Format v2", Roman Danyliw, Paul Stoecker, 2015-06-20, The Incident Object Description Exchange Format (IODEF) defines a data representation for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. "MILE Implementation Report", Christopher Inacio, daisu-mi@nc.u-tokyo.ac.jp, 2015-07-05, 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. Mobility for IPv4 (mip4) ------------------------ "Flow Binding Support for Mobile IP", Sri Gundavelli, Kent Leung, George Tsirtsis, Alex Petrescu, 2015-06-21, This specification defines extensions to Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses. 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. "The Comparison of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 2015-05-19, This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 2015-05-05, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Christer Holmberg, Salvatore Loreto, Gonzalo Camarillo, 2015-03-05, SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2015-06-16, This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, associated with multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. "WebRTC MediaStream Identification in the Session Description Protocol", Harald Alvestrand, 2015-04-28, This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. "Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)", Marc Petit-Huguenin, Ari Keranen, 2015-03-09, This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Ari Keranen, Jonathan Rosenberg, 2015-03-09, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. 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). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla, Justin Uberti, 2015-01-15, This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows 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. The above mechanism is also referred to as "trickle ICE". "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar, 2015-07-05, The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. Typically media associated with individual media descriptions ("m=" lines) represent RTP sessions and are thus carried over individual underlying transport layer flows. For scenarios where SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions, it is required to understand the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Thomas, Enrico Marocco, Christer Holmberg, 2015-07-06, The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2015-01-20, In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in independent RTP streams. This is called simulcast. This document discusses the best way of accomplishing simulcast in RTP and how to signal it in SDP. A solution is defined by making an extension to SDP, and using RTP/RTCP identification methods to relate RTP streams belonging to the same media source. The SDP extension consists a new media level SDP attribute that express capability to send and/or receive simulcast RTP streams. One part of the RTP/RTCP identification method is included as a reference to a separate document, since it is useful also for other purposes. "SDP-based Data Channel Negotiation", Keith Drage, Raju Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-04-10, The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. Data channel setup can be done using either the internal in-band band (also referred to as 'internal' for the rest of the document) Data Channel Establishment Protocol or some external out-of-band simply referred to as 'external negotiation' in the rest of the document . This document specifies how the SDP offer/answer exchange can be used to achieve such an external 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. This document is intended to be used wherever data channels are used. "MSRP over Data Channels", Keith Drage, Raju Makaraju, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-03-09, This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 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). "ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", Paal-Erik Martinsen, Tirumaleswar Reddy, Prashanth Patil, 2015-06-22, 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. "IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.", Suhas Nandakumar, 2015-07-02, RTP provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The RTP specification [RFC3550] establishes a registry of profile names for use by higher-level control protocols, such as the SDP, to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. Multiprotocol Label Switching (mpls) ------------------------------------ "Multi-path Label Switched Paths Signaled Using RSVP-TE", Kireeti Kompella, Mike Hellers, Ravi Singh, 2015-03-09, This document describes extensions to Resource ReSerVation Protocol - Traffic Engineering for the set up of multi-path Traffic Engineered Label Switched Paths (LSPs) in Multi Protocol Label Switching (MPLS) and Generalized MPLS networks, i.e., LSPs that conform to traffic engineering constraints, but follow multiple independent paths from source to destination. "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping", Elisa Bellagamba, Greg Mirsky, Loa Andersson, Pontus Skoldstrom, David Ward, John Drake, 2015-01-26, This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. "Temporal and hitless path segment monitoring", Alessandro D'Alessandro, Loa Andersson, Manuel Paul, Satoshi Ueno, Kaoru Arai, Yoshinori Koike, 2015-02-27, The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2015-02-26, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) and MPLS based Transport Profile (TP). "MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology", Weiqiang Cheng, Lei Wang, Han Li, Huub van Helvoort, Kai Liu, Jie Dong, He Jia, Fang Li, Yang Jian, Junfang Wang, 2015-06-17, 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 in RFC 5654 for optimized ring protection is analyzed. "MPLS Transport Profile Linear Protection MIB", Kingston Selvaraj, Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin, 2015-02-03, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. "Relayed Echo Reply mechanism for LSP Ping", Luo Jian, Lizhong Jin, Tom Nadeau, George Swallow, 2015-07-06, In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. "mLDP Node Protection", IJsbrand Wijnands, Kamran Raza, Eric Rosen, Alia Atlas, Jeff Tantsura, Quintin Zhao, 2015-02-09, This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) that has been built by "Multipoint Label Distribution Protocol"(mLDP). In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs. The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. "Residence Time Measurement in MPLS network", Greg Mirsky, Stefano Ruffini, Eric Gray, John Drake, Stewart Bryant, Sasha Vainshtein, 2015-07-02, 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. "Use Cases and Requirements for MPLS-TP multi-failure protection", Zhenlong Cui, Rolf Winter, Himanshu Shah, Sam Aldrin, Masahiro Daikoku, 2015-07-06, For the Multiprotocol Label Switching Transport Profile (MPLS-TP) linear protection capable of 1+1 and 1:1 protection has already been defined. That linear protection mechanism has not been designed for handling multiple, simultaneously occuring failures, i.e. multiple failures that affect the working and the protection entity during the same time period. In these situations currently defined protection mechanisms would fail. This document introduces use cases and requirements for mechanisms that are capable of protecting against such failures. It does not specify a multi-failure protection mechanism itself. "Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane", Nagendra Kumar, George Swallow, Carlos Pignataro, Nobo Akiya, Sriganesh Kini, Hannes Gredler, Mach Chen, 2015-04-25, 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 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. "Bidirectional Forwarding Detection (BFD) Directed Return Path", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2015-03-05, Bidirectional Forwarding Detection (BFD) is expected to monitor bi- directional paths. When a BFD session monitors in its forward direction an explicitly routed path there is a need to be able to direct egress BFD peer to use specific path as reverse direction of the BFD session. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, George Swallow, 2015-04-30, This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is a key goal of the MPLS Fabric architecture. "RFC6374 UDP Return Path", Stewart Bryant, Siva Sivabalan, Sagar Soni, 2015-04-29, This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. "Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification", Nobo Akiya, George Swallow, Carlos Pignataro, Loa Andersson, Mach Chen, 2015-05-01, The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the "Reply via Specified Path (5)" Reply Mode value to easily indicate the reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC7110. "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2015-03-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. "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, 2015-06-11, The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal-Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when 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 mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of Entropy Label. This document updates RFC4379, RFC6424 and RFC6790. "Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces", Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, 2015-01-08, This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 4379. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC4379 and RFC6424. "LDP Extensions to Support Maximally Redundant Trees", Alia Atlas, Kishore Tiruveedhula, Chris Bowers, Jeff Tantsura, IJsbrand Wijnands, 2015-07-04, 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 LDP MT-ID space. "Application-aware Targeted LDP", Santosh Esale, Raveendra Torvi, Chris Bowers, Luay Jalil, Uma Chunduri, Zhenbin Li, Kamran Raza, 2015-02-17, Recent targeted LDP applications such as remote loop-free alternates (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC-label bindings over the session. "Entropy labels for source routed stacked tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir, Xiaohu Xu, Wim Henderickx, Jeff Tantsura, 2015-03-05, Source routed tunnel stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed stacked tunnels. "Handling the TC and TTL fields in a Label Stack Entry when the Generic Associated Channel Label is Present", Sasha Vainshtein, Loa Andersson, Adrian Farrel, 2015-06-16, This document clarifies handling of the Traffic Class (TC) and Time- to-Live (TTL) fields of a Label Stack Entry that contains the Generic Associated Channel (G-ACh) Label (GAL). These clarifications are intended to aid interoperability of implementations. Original handling was defined in RFC 5586, and this document updates that RFC. "LSP Self-Ping", Raveendra Torvi, Ron Bonica, Ina Minei, Michael Conn, Dante Pacella, Luis Tomotaki, Mark Wygant, 2015-06-15, When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This memo describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, 2015-03-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 obsoletes RFC6824 [5] through clarifications and modifications, primarily driven by deployment experience. "Analysis of MPTCP residual threats and possible fixes", Marcelo Bagnulo, Christoph Paasch, Fernando Gont, Olivier Bonaventure, Costin Raiciu, 2015-03-27, This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them. "Use Cases and Operational Experience with Multipath TCP", Olivier Bonaventure, Christoph Paasch, Gregory Detal, 2015-07-06, This document discusses both use cases and operational experience with Multipath TCP in real world networks. It lists several prominent use cases for which Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases. Network Configuration (netconf) ------------------------------- "RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-07-06, This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. "YANG Patch Media Type", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-07-06, This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. "NETCONF Server and RESTCONF Server Configuration Models", Kent Watsen, Jürgen Schönwälder, 2015-07-06, This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listen on, call-home parameters, client authentication, and other related configuration parameters. "Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)", Kent Watsen, Joe Clarke, Mikael Abrahamsson, 2015-07-06, This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based device, configured with just its factory default settings, and its rightful owner's network management system (NMS). "NETCONF Call Home and RESTCONF Call Home", Kent Watsen, 2015-06-15, 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. "RESTCONF Collection Resource", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-01-30, This document describes a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method. "YANG Module Library", Andy Bierman, Martin Bjorklund, Kent Watsen, 2015-07-06, This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information. Network-Based Mobility Extensions (netext) ------------------------------------------ "Logical-interface Support for Multi-access enabled IP Hosts", Telemaco Melia, Sri Gundavelli, 2015-03-06, A Logical-interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical-interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 2015-02-25, Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. NETCONF Data Modeling Language (netmod) --------------------------------------- "A YANG Data Model for Routing Management", Ladislav Lhotka, Acee Lindem, 2015-05-25, This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), and routing protocols. "JSON Encoding of Data Modeled with YANG", Ladislav Lhotka, 2015-06-12, This document defines encoding rules for representing configuration, state data, RPC input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2015-07-06, 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. "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", Martin Bjorklund, 2015-07-06, YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. "SYSLOG YANG model", Clyde Wildes, 2015-07-06, This document describes a data model for Syslog protocol which is used to convey event notification messages. "Network Access Control List (ACL) YANG Data Model", Dean Bogdanovic, Kiran Sreenivasa, Lisa Huang, Dana Blair, 2015-06-25, This document describes a data model of Access Control List (ACL) basic building blocks. "Defining and Using Metadata with YANG", Ladislav Lhotka, 2015-06-10, This document defines a YANG extension statement that allows for defining syntax of metadata annotions in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. Network File System Version 4 (nfsv4) ------------------------------------- "NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description", Tom Haynes, 2015-04-28, This Internet-Draft provides the XDR description for NFSv4 minor version two. "NFS Version 4 Minor Version 2", Tom Haynes, 2015-04-28, This Internet-Draft describes NFS version 4 minor version two, describing the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version two include: Server Side Copy, Application I/O Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. "Remote Procedure Call (RPC) Security Version 3", Andy Adamson, Nicolas Williams, 2015-07-06, This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to server (constructed by generic composition), security label assertions for multi-level and type enforcement, structured privilege assertions, and channel bindings. "NFSv4 migration: Implementation experience and spec issues to resolve", David Noveck, Piyush Shivam, Chuck Lever, Bill Baker, 2015-03-02, The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen, explores the options available for curing the issues, and explains the choices made in updating the NFSv4.0 and NFSv4.1 specifications, to address migration. "NFSv4.0 migration: Specification Update", David Noveck, Piyush Shivam, Chuck Lever, Bill Baker, 2015-07-04, The migration feature of NFSv4 allows for responsibility for a single filesystem to move from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document clarifies and corrects RFC7530 (the NFSv4.0 specification) to address these problems. "Requirements for pNFS Layout Types", Tom Haynes, 2015-01-30, This document provides help in distinguishing between the requirements for Network File System (NFS) version 4.1's Parallel NFS (pNFS) and those those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. As this document clarifies RFC5661, it effectively updates RFC5661. "Parallel NFS (pNFS) Flexible File Layout", Benny Halevy, Tom Haynes, 2015-02-09, The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Layout Type is defined in this document as an extension to pNFS to allow the use of storage devices in a fashion such that they require only a quite limited degree of interaction with the metadata server, using already existing protocols. Client side mirroring is also added to provide replication of files. "Multiple NFSv4 Domain Namespace Deployment Guidelines", Andy Adamson, Nicolas Williams, 2015-01-23, This document describes administrative constraints to the deployment of the NFSv4 protocols required for the construction of an NFSv4 file system namespace supporting the use of multiple NFSv4 domains and utilizing multi-domain capable file systems. Also described are administrative constraints to name resolution and security services appropriate to such a system. Such a namespace is a suitable way to enable a Federated File System supporting the use of multiple NFSv4 domains. "NFSv4 Version Management", David Noveck, 2015-07-12, This document describes the management of versioning within the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC5661. "Parallel NFS (pNFS) SCSI Layout", Christoph Hellwig, 2015-04-25, Parallel NFS (pNFS) extends Network File Sharing version 4 (RFC5661) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS, the pNFS Block/Volume Layout (RFC5663) specifies the additional extensions for use of pNFS with block-and volume-based storage, while this document provides extensions to the pNFS Block/Volume Layout document to provide reliable fencing and better device discoverability for SCSI based shared storage devices. "Size-Limited Bi-directional Remote Procedure Call On Remote Direct Memory Access Transports", Chuck Lever, 2015-06-01, Recent minor versions of NFSv4 work best when ONC RPC transports can send ONC RPC transactions in both directions. This document describes conventions that enable RPC-over-RDMA version 1 transport endpoints to interoperate when operation in both directions is necessary. Network Function Virtualization (nfvrg) --------------------------------------- "Resource Management in Service Chaining", Seungik Lee, Sangheon Pack, Myung-Ki Shin, EunKyoung Paik, 2015-03-09, This document specifies problem definition and use cases of NFV resource management in service chaining for path optimization, traffic optimization, failover, load balancing, etc. It further describes design considerations and relevant framework for the resource management capability that dynamically creates and updates network forwarding paths (NFPs) considering resource constraints of NFV infrastructure. "Verification of NFV Services : Problem Statement and Challenges", Myung-Ki Shin, Ki-Hyuk Nam, Sangheon Pack, Seungik Lee, Ram (Ramki) Krishnan, Tae-wan Kim, 2015-07-03, NFV relocates network functions from dedicated hardware appliances to generic servers, so they can run in software. However, incomplete or inconsistent configuration of virtualized network functions (VNF) and forwarding graph (FG, aka service chain) could cause break-down of the supporting infrastructure. In this sense, verification is critical for network operators to check their requirements and network properties are correctly enforced in the supporting infrastructures. Recognizing these problems, we discuss key properties to be checked on NFV-enabled services. Also, we present architectural challenging issues related to verification in NFV environments. "Resource Management in Service Chaining", Seungik Lee, Sangheon Pack, Myung-Ki Shin, EunKyoung Paik, Rory Browne, 2015-07-06, This document specifies problem definition and use cases of NFV resource management in service chaining for path optimization, traffic optimization, failover, load balancing, etc. It further describes design considerations and relevant framework for the resource management capability that dynamically creates and updates network forwarding paths (NFPs) considering resource constraints of NFV infrastructure. Network Management (nmrg) ------------------------- "Extending IP Flow-Based Network Monitoring with Location Information", Olivier Festor, Abdelkader Lahmadi, Rick Hofstede, Aiko Pras, 2015-07-06, IP Flow-based monitoring lacks a mechanism to associate measured IP Flow information with the geographic location of the device where the IP Flows have been observed. This document defines a set of guidelines and best practices to extend IP Flow monitoring protocols with location information of the device (both fixed and mobile) that acts as an IP Flow metering process. "Autonomic Networking Use Case for Distributed Detection of SLA Violations", Jeff, Lisandro Granville, Alex Clemm, Alberto Prieto, 2015-05-07, This document describes a use case for autonomic networking in distributed detection of Service Level Agreement (SLA) violations. It is one of a series of use cases intended to illustrate requirements for autonomic networking. Individual Submissions (none) ----------------------------- "An IPv4 Flowlabel Option", Thomas Dreibholz, 2015-07-05, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 2015-06-26, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 2013-02-25, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2015-07-05, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 2015-07-05, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. "DNS Glue RR Survey and Terminology Clarification", Peter Koch, 2015-03-09, This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different top level domains. "Channel Bindings for TLS based on the PRF", Simon Josefsson, 2015-03-02, This document specify how to compute the 'tls-unique-prf' data that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). Applications of this include SASL- based protocols like IMAP, SMTP and XMPP. The channel binding 'tls- unique-prf' defined in this document is an alternative to 'tls- unique' as described by RFC 5929 and used by SCRAM and GS2. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2015-07-05, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 2015-07-05, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Handle Resolution Option for ASAP", Thomas Dreibholz, 2015-07-05, This document describes the Handle Resolution option for the ASAP protocol. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 2015-07-05, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 2015-04-18, This document specifies the Saratoga transfer protocol. Saratoga was originally developed to transfer remote-sensing imagery efficiently from a low-Earth-orbiting satellite constellation, but is useful in many other scenarios, including ad-hoc peer-to-peer communications, large-scale scientific sensing, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. Saratoga can also cope with very large files for exascale computing. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "The BagIt File Packaging Format (V0.97)", John Kunze, Justin Littman, Liz Madden, Ed Summers, Andy Boyko, Brian Vargas, 2015-06-23, This document specifies BagIt, a hierarchical file packaging format for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive "tags" and a "payload" but does not require knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based storage and transfer. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, Takuya Miyasaka, 2015-03-22, IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines how to extend the PCEP to support the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. "BGP Extended Community for QoS Marking", Thomas Knoll, 2015-01-19, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "BGP Class of Service Interconnection", Thomas Knoll, 2015-05-14, This document focuses on Class of Service Interconnection at inter- domain interconnection points. It specifies two new transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability" is deliberately kept simple and denotes the general EF, AF Group BE and LE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. "RSVP-TE Recovery Extension for data plane initiated reversion, and protection timer signaling", Attila Takacs, Francesco Fondelli, Benoit Tremblay, Zafar Ali, 2015-07-06, RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently recovery signaling does not support the request for revertive protection and recovery timers values. This document extends the PROTECTION Object format allowing sub-TLVs, and defines two sub-TLVs to carry wait-to-restore and hold-off intervals. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 2015-07-05, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "HTTP Live Streaming", Roger Pantos, 2015-04-15, This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol. "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2015-07-06, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2015-05-14, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the ip6.arpa zone for IPv6 address space assigned to many customers. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2014-03-20, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources in the legal domain. "Mesh Structured Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 2015-04-30, This document tries to address an approach for the reorganization of the entire network in a large address space. It describes how a three-tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and some sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6. This document also tries to come out with an approach how IP switch based network can perform as good as ATM network for the processing of real time traffic. "Integrating rxgk with AFS", Simon Wilkinson, Benjamin Kaduk, 2015-05-21, This document describes how the new GSSAPI-based rxgk security class for RX is integrated with the AFS application protocol. It describes a number of extensions to the basic rxgk protocol, clarifies a number of implementation issues, and provides values for the application- specific elements of rxgk. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Global SA46T Address Format", Naoki Matsuhira, 2015-01-22, This document proposes Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) Global Address Format. SA46T can apply to organization's network individually, but if coordination between the organizations made, the total number of times of encapsulations and decapusulations can be reduced. That coordination is achieved by using same SA46T address format, that is Global address. This document proposes SA46T Global address format. SA46T is a gateway technology, not protocol. But SA46T Global Address needs IANA assignment, so this document should be categorized standard track or experimental. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Specification", Naoki Matsuhira, 2015-01-22, This document specifies Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) base specification. SA46T makes backbone network to IPv6 only. And also, SA46T can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 2010-03-23, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Advanced Groupware Access Protocol", Iulian Radu, 2015-04-21, The Advanced Groupware Access Protocol, (AGAP) allows a client to access and store electronic mail messages, contacts, events, files, and configurations on a server. The electronic mail messages can be grouped in folders. AGAP also provides the capability for an offline client to resynchronize with the server. AGAP does not specify a means of posting electronic mail messages; this function is handled by a mail transfer protocol such as SMTP [RFC2821] . It also does not specify a means for exchanging messages with contacts that are reported as being online; this function is handled by an instant messaging protocol such as XMPP [RFC3921] . AGAP includes the following operations for electronic mail messages: creating, deleting, renaming, moving and coping mail folders; checking for new messages; permanently removing messages; moving and coping messages between folders; fetching information about a message; setting and clearing tags for messages; searching in messages; retrieving only a part of a message; marking messages as SPAM; deleting attachments from a message. AGAP includes the following operations to manipulate the contacts: creating, deleting, moving, coping, tagging, and searching contacts; checking if a contact is online; fetching information about a contact. AGAP includes the following operations related to the use of the events: creating, deleting, moving, coping and tagging events in calendar; fetching events details; searching for events. All items are read and written in format XML encoded UTF-8 [RFC3629] and each item is identified by a unique alphanumeric identifier. AGAP is designed to support access only to a single server per connection. It is also designed to balance the volume of text exchanged between the server and clients and its readability by humans for debugging. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana, Preethi Natarajan, Randall Stewart, Michael Tuexen, 2015-05-29, The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. "Registry Data Escrow Specification", Francisco Arias, Gustavo Lozano, Shoji Noguchi, 2015-04-22, This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than domain name registries. "Clarification of Proper Use of "@" (at sign) in URI-style Components", Robert Simpson, 2010-07-30, Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. "Port Management To Reduce Logging In Large-Scale NATs", Tina Tsou, Weibo Li, Tom Taylor, Jing Huang, 2015-04-26, Various IPv6 transition strategies require the introduction of large- scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low. "Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)", Ala Hamarsheh, 2011-01-19, This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14, This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. "DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob Schlyter, Guy Bailey, 2015-04-06, The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes how such trust anchors are published. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology with IPv4 Address Sharing", Naoki Matsuhira, 2015-01-22, This document specifies Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology with IPv4 Address Sharing (SA46T-AS) base specification. SA46T-AS is basically the same technology with SA46T, however that have IPv4 address sharing capability. SA46T-SA is gateway technology, not protocol. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2015-02-28, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, 2015-02-28, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 2015-07-05, This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 2015-07-05, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai Yang, Jianping Wu, Jun Bi, 2015-06-14, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance. "Cloud Reference Framework", Bhumip Khasnabish, JunSheng Chu, SuAn Ma, Ning So, Paul Unbehagen, Monique Morrow, Masum Hasan, Yuri Demchenko, Meng Yu, 2015-04-09, This document presents a cloud reference framework that intends to provide a basis for designing interoperable cloud services and their integration into existing open Internet and enterprise IT infrastructures. In general, a cloud-based system utilizes virtualized computing / communications / storage resources and applications, and allows their combined provisioning as complex infrastructure services. In the emerging cloud-based virtualized infrastructures and services are provisioned on on-demand basis, and configured for specific customer needs or tasks. The reference framework is based on the survey of the SDOs and WGs that are focusing on cloud-based systems and services (Cloud SDO, I-D.Khasnabish-cloud-sdo-survey), on-going standardisation activities and other research and developments in the cloud computing technology area. Both intra-cloud and inter-cloud reference frameworks are presented and the requirements to the general functional layers and components are discussed. "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010", Stephen Slevinski, Valerie Sutton, 2011-01-03, For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "The Quality for Service Protocol", Jose Garcia, Jacobo Lajo, Luis Vizcaino, Gonzalo Fernandez, Carlos Barcenilla, Monica Cortes, Joaquin Salvachua, Juan Quemada, 2015-03-27, This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality for Service Protocol (Q4S) provides a mechanism for latency, jitter, bandwidth and packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependant (e.g. increase quality, reduce bit-rate) or even network dependant (e.g. change connection's quality profile). "A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)", Roozbeh Atarius, 2015-03-03, This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal encoded digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. "Inter-ALTO Communication Problem Statement", Zbigniew Dulinski, Piotr Wydrych, Rafal Stankiewicz, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) protocol has been standardized in RFC7285 to ease better-than-random overlay connection management. Due to various reasons, optimization capabilities of ALTO servers are limited by the fact that it may not be possible for an ALTO server to compute costs for source/destination pairs correctly if a source and/or a destination is outside the administrative domain it belongs to. In other words, an ALTO server may be generally unable to optimize the traffic with only locally available topology information. Therefore, it is proposed that operators of distinct administrative domains may agree on topology- and policy-related information exchange through a standardized inter-ALTO communication framework. This document provides a rationale for design, standardization, and implementation of the inter-ALTO communication framework. "Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)", Radia Perlman, Donald Eastlake, Mingui Zhang, Anoop Ghanwani, Hongjun Zhai, 2015-07-05, Extending TRILL to multiple levels has challenges that are not addressed by the already-existing capability of IS-IS to have multiple levels. One issue is with the handling of multi-destination packet distribution trees. Another issue is with TRILL switch nicknames. There have been two proposed approaches. One approach, which we refer to as the "unique nickname" approach, gives unique nicknames to all the TRILL switches in the multilevel campus, either by having the level-1/level-2 border TRILL switches advertise which nicknames are not available for assignment in the area, or by partitioning the 16-bit nickname into an "area" field and a "nickname inside the area" field. The other approach, which we refer to as the "aggregated nickname" approach, involves hiding the nicknames within areas, allowing nicknames to be reused in different areas, by having the border TRILL switches rewrite the nickname fields when entering or leaving an area. Each of those approaches has advantages and disadvantages. This informational document suggests allowing a choice of approach in each area. This allows the simplicity of the unique nickname approach in installations in which there is no danger of running out of nicknames and allows the complexity of hiding the nicknames in an area to be phased into larger installations on a per- area basis. "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, 2015-04-05, FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 2015-02-28, This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi Kawamura, Randy Bush, Cristel Pelsser, 2012-06-21, BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping. "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 2015-02-28, This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "A SAVI Solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin, 2015-02-04, This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. "Supporting Explicit Inclusion or Exclusion of Abstract Nodes for a Subset of P2MP Destinations in Path Computation Element Communication Protocol (PCEP).", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy, 2015-04-23, The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). The RFC 6006 and RFC 7334 describes these mechanisms for intra and inter domain path computation via PCE(s). This document describes the motivation and PCEP extension for explicitly specifying abstract nodes for inclusion or exclusion for a subset of destinations during P2MP path computation via PCE(s). "Non-Normative Synonyms in RFCs", Tony Hansen, dcrocker, 2015-06-23, Specifications in RFCs contain normative keywords, as defined in RFC 2119, to signify requirements, permission or prohibitions. These include MUST, SHOULD and MAY, which are commonly recorded in all CAPITALS (but need not be). The RFC 2119 words are sometimes also used with non-normative meaning; this non-normative usage can be confusing and it is better to restrict the RFC 2119 words to be used solely as normative directives. Happily, natural languages permit variation in phrasing, so that meaning can be retained without use of this otherwise-normative vocabulary. For such situations, this document provides some alternatives to the normative vocabulary of RFC 2119. "User-Managed Access (UMA) Profile of OAuth 2.0", Thomas Hardjono, Eve Maler, Maciej Machulak, Domenico Catalano, 2015-04-04, User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policies. "BGPSEC Design Choices and Summary of Supporting Discussions", Kotikalapudi Sriram, 2015-07-02, This document has been written to capture the design rationale for the individual draft-00 version of BGPSEC protocol specification (I- D.lepinski-bgpsec-protocol-00). It lists the decisions that were made in favor of or against each design choice, and presents brief summaries of the arguments that aided the decision process. A similar document can be published in the future as the BGPSEC design discussions make further progress and additional design considerations are discussed and finalized. "NVGRE: Network Virtualization using Generic Routing Encapsulation", Pankaj Garg, Yu-Shun Wang, 2015-04-13, This document describes the usage of Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant datacenters. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data plane aspect of NVGRE. "TFRC-based Congestion Control for Saratoga", Wesley Eddy, Lloyd Wood, Will Ivancic, 2015-04-18, This document specifies the use of TCP-Friendly Rate Control (TFRC) with the Saratoga data transfer protocol. The necessary conventions that a Saratoga sender and receiver implementation must follow if they wish to enable the use of TFRC are described. "Congestion control for the Saratoga protocol", Lloyd Wood, Wesley Eddy, Will Ivancic, 2015-04-18, Saratoga is a data transfer protocol designed to carry potentially large volumes of data over difficult network paths, often including only a single high-rate link and only one application flow. As the requirements for use vary across deployment environments, the base Saratoga specification only assumes that an implementation will be able to clock packets out at a configurable rate, and beyond this specifies no inherent or particular congestion-control behaviour. The design of Saratoga deliberately supports the integration of congestion-control algorithms without modification to the base protocol. This document describes how congestion control can be supported in the Saratoga transfer protocol. Saratoga is intended for use in private networks, where its use is engineered as a single flow to fill a link. However, as Saratoga is implemented over UDP, it can be multiplexed, and can be run across the public Internet, in which case congestion control in accordance with the UDP Guidelines becomes necessary. "Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing Li, 2015-07-03, This document discusses an extension of the algorithmic translation between IPv4 and IPv4-translatable IPv6 addresses. The extended address format contains transport-layer port set identification (PSID) which allows several IPv6 nodes to share a single IPv4 address with each node managing a different range of ports. This address format extension can be used for IPv4/IPv6 translation, as well as IPv4 over IPv6 tunneling. "Cross Stratum Optimization Architecture for Optical as a Service", Hui Yang, Yongli Zhao, Jie Zhang, Young Lee, Yi Lin, Fatai Zhang, 2015-05-18, Data centers based applications provide a wide variety of services such as cloud computing, video gaming, grid application and others. Currently application decisions are made with little information concerning underlying network used to deliver those services so that such decisions cannot be the most optimal from both network and application resource utilization and quality of service objectives. This document presents a novel architecture of Cross Stratum Optimization for application and network resource in dynamic optical networks. Several global load balancing strategies are proposed and demonstrated by experiments in Optical as a Service experimental environment. "The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Thomas Clausen, Axel Verdiere, Jiazi Yi, Afshin Niktash, Yuichi Igarashi, Hiroki Satoh, Ulrich Herberg, Cedric Lavenu, Thierry Lys, Justin Dean, 2015-07-06, This document describes the Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). "PIM Route Flap Damping", fangwei hu, Zheng Zhang, BenChong Xu, 2015-07-05, This document describes the route flap damping functions for PIM-SM [RFC4601], to reduce the processing load caused by the instability of routing peers. "A General Framework of Source Address Validation and Traceback for IPv4/IPv6 Transition Scenarios", Hui Deng, Guangwu Hu, Jun Bi, Mingwei Xu, Fan Shi, 2015-05-12, SAVI (Source Address Validation Improvement) is an excellent mechanism for anti-IP-spoofing, which was advocated by IETF but only focused on single-stack or simple network scenarios right now. To the best of our knowledge, existing studies have not paid attention to the IPv4/IPv6 transition scenarios. However, since IPv4/IPv6 transition schemes are plenty and various, one solution cannot meet all requirements of them. In this draft, we present a SAVI-based general framework for IP source address validation and traceback in the IPv4/IPv6 transition scenarios, which achieve this by extracting out essential and mutual properties from these schemes, and forming sub-solutions for each property. When one transition scheme is composed from various properties, its IP source address validation and traceback solution is directly comprised by the corresponding sub-solutions. Thus, the most exciting advantage of this framework is that it is a once-and-for-all solution no matter how transition schemes change. "SAVI Requirements and Solutions for ISP IPv6 Access Network", Fan Shi, 2015-05-09, Internet is always confronted with many security threats based on IP address spoofing which can enable impersonation and malicious traffic redirection. Unfortunately, the Internet architecture fails to provide the defense mechanism. Source Address Validation Improvement (SAVI) was developed to prevent IP source address spoofing. Especially, the mechanism is essential for ISPs. However, due to the diversity of address assignment methods, SAVI solution is also different accordingly. This document describes five scenarios of ISPs'IPv6 access network, and moreover, states its SAVI requirements and tentative solutions accordingly. "A PMIPv6-based solution for Distributed Mobility Management", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, 2015-03-05, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes multiple solutions for network-based distributed mobility management inspired by the well known Proxy Mobile IPv6. "Unified User-Agent String", Mateusz Karcz, 2014-11-10, User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use. "Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu, 2015-05-14, IETF Source Address Validation Improvements (SAVI) working group is chartered for source address validation within the first hop from the end hosts, i.e., preventing a node from spoofing the IP source address of another node in the same IP link. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some source address validation techniques beyond the first hop (SAVI-BF) may be needed to complement SAVI and protect the networks from spoofing based attacks. In this document, we first propose three desired features of the SAVI-BF techniques. Then we analyze the problems of the current SAVI-BF technique, ingress filtering. Finally, we discuss the directions that we can explore to improve SAVI-BF. "Cross Stratum Optimization enabled Path Computation", Dhruv Dhody, Young Lee, Luis Contreras, Oscar Gonzalez de Dios, Nicola Ciulli, 2015-01-21, Applications like cloud computing, video gaming, HD Video streaming, Live Concerts, Remote Medical Surgery, etc are offered by Data Centers. These data centers are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. Cross stratum application/network optimization focus on the challenges and opportunities presented by data center based applications and carriers networks together [CSO-DATACNTR]. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. [RFC4655] explains the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document explains the architecture for CSO enabled Path Computation. "Tunneling Compressing and Multiplexing (TCM) Traffic Flows. Reference Model", Jose Saldana, Dan Wing, Julian Navajas, Muthu Perumal, Fernando Blanco, 2015-06-13, Tunneling, Compressing and Multiplexing (TCM) is a method for improving the bandwidth utilization of network segments that carry multiple small-packet flows in parallel sharing a common path. The method combines different protocols for header compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth. The amount of packets per second can also be reduced. This document describes the TCM framework and the different options which can be used for each layer (header compression, multiplexing and tunneling). "SNMPD to use cache and shared database based on MIB Classification", Haresh Khandelwal, 2012-03-29, This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. "IPv6 Prefix Properties", Jouni Korhonen, Sri Gundavelli, Pierrick Seite, Dapeng Liu, 2015-07-06, This specification defines an extension to the IPv6 stateless address autoconfiguration procedure. New options with meta data are defined that describe the properties and other prefix class meta data associated with the prefix. The stateless address autoconfiguration procedure and end hosts can make use of the additional properties and class information when selecting source address prefixes for a particular uses and use cases. This specification updates RFC4862. "Representing Label Generation Rulesets using XML", Kim Davies, Asmus Freytag, 2015-06-24, This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and specific Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. "Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya Murakami, Simon Perreault, 2013-05-17, This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. "PMIPv6-based Distributed Mobility Management", Jaehwoon Lee, Young-Han Kim, 2015-06-17, Proxy Mobile IPv6 (PMIPv6) is the network-based mobility management protocol where access network supports the mobility of a mobile node on behalf of the MN. In PMIPv6, the location information of the MN should be registered to Localized Mobility Anchor and communication must be established via the LMA. Therefore, the performance can be degraded due to traffic concentration and congestion possibility. One method to overcome the above problems is to exploit the distributed mobility management (DMM) mechanism to distribute the LMA function to all access routers within the PMIPv6 domain. This document presents a fully distributed mobility management mechanism in PMIPv6-based network. In this mechanism, there is no need for the location management function to register the location of the MN. "PMIPv6-based distributed anchoring", Carlos Bernardos, Juan-Carlos Zúñiga, 2015-03-09, Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called distributed gateway). The distributed gateway is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The draft focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. This draft introduces the concept of distributed logical interface (at the distributed gateway), which is a software construct that allows to easily hide the change of anchor from the mobile node. Additionally, the draft describes how to provide session continuity in inter-domain scenarios in which dynamic tunneling or signaling between distributed gateways from different operators is not allowed. "More Raw Public Keys for IKEv2", Tero Kivinen, Paul Wouters, Hannes Tschofenig, 2015-04-20, The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In constrained environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2. "The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.", Huaimo Chen, Dhruv Dhody, 2015-02-28, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. "Address Selection for DMM", Vic Liu, Deng Lingli, Dapeng Liu, Xinpeng Wei, Juan Liu, 2015-07-06, In DMM scenario, it is possible for the MN to use multiple mobility anchor points and corresponding prefixes. In that case, MN needs to know the property of the addresses then it can select the optimized one for application to use. This document defines new IP network prefix types to assist address selection for applications. "Requirements for Message Access Control", Trevor Freeman, Jim Schaad, Patrick Patterson, 2015-03-08, S/MIME delivers confidentiality, integrity, and data origination authentication for email. However, there are many situations where organizations also want robust access control applied to information in messages. The Enhanced Security Services (ESS) RFC5035 for S/MIME defines an access control mechanism for email, but the access check happens after the data is decrypted by the recipient which devalues the protection afforded by the cryptography and provides very weak guarantees of policy compliance. Another major issues for S/MIME is its dependency on a single type of identity credential, an X.509 certificate. Many users on the Internet today do not have X.509 certificates and therefore cannot use S/MIME. Furthermore, the requirement to discover the X.509 certificate for every recipient of an encrypted message by the sender has proven to be an unreliable process for a number of reasons. This document presents requirements for an alternative model to ESS to address the identified issues with access control in order to deliver more robust compliance for S/MIME protected messages. This document describes an access control model which uses cryptographic keys to enforce access control policy decisions where the policy check is performed prior to the decryption of the message contents. This authorization model can be instantiated using many existing standards and is in not intended to be a one off just for email, being applicable to other data types. This document also presents requirements for the abstraction of the specifics of the authentication technologies used by S/MIME users. The abstraction makes it possible for other forms of authentication credentials to be used with S/MIME thereby enabling much broader adoption. The authentication abstraction model also removes the dependency on the need to discover encryption keys by the sender. This abstraction can be used independently from access control to enable simple scenarios where authentication of the recipient is sufficient to grant access to the message. The name Plasma was assigned to this effort as part of the IETF process. It is derived from PoLicy enhAnced Secure eMAil. "Private Enterprise Number (PEN) practices and Internet Assigned Numbers Authority (IANA) registration considerations", Pearl Liang, Alexey Melnikov, David Conrad, 2015-07-06, Private Enterprise Numbers (PENs) are a technical protocol parameter frequently assigned for use in the management of network connected equipment or software via SNMP-based network management systems, LDAP, DIAMETER or GSS-API. This document discusses what a Private Enterprise Number (PEN) is, common uses of PENs, and registration procedures for IANA Considerations. The registration procedures include instructions and requirements for obtaining a new Private Enterprise Number, modifying existing numbers, and the removal of existing numbers. "A Framework and Information Model for Telephone-Related Queries (TeRQ)", Jon Peterson, 2015-07-06, As telephone services migrate to the Internet, Internet applications require access to diverse information about telephone numbers. ENUM, for example, applied the DNS to the problem of finding URIs for telephone services on the Internet. The intrinsic limitations in the query/response semantics of the DNS, however, have often been strained by the requirements for accessing information about telephone numbers. This document therefore proposes a protocol- independent framework and information model for querying and responding to requests concerning telephone numbers and call routing that allows a richer expression of both questions and answers. "Customer Edge Router Identification Option", Chris Donley, Michael Kloberdans, John Brzozowski, Chris Grundemann, 2015-02-13, Addressing mechanisms supporting DHCPv6 Prefix Delegation in home networks such as those described in CableLabs' eRouter specification and the HIPnet Internet-Draft require identification of the customer edge router (CER) as the demarcation between the customer network and the service provider network. This document reserves a DHCPv6 option to identify the CER. "NAT traversal for LISP", Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White, 2015-02-15, This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. "LISP-DDT Referral Internet Groper (RIG)", Dino Farinacci, Amit Jain, Isidor Kouvelas, Darrel Lewis, 2014-12-16, A simple tool called the LISP-DDT Referral Internet Groper or 'rig' can be used to query the LISP-DDT hierarchy. This draft describes how the 'rig' tool works. "LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal, Parantap Lahiri, 2015-03-23, This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. "SA46T Address Translator", Naoki Matsuhira, Katsuhiro Horiba, Yukito Ueno, Osamu Nakamura, 2015-02-15, This document specifies SA46T Address Translator (SA46T-AT) specification. SA46T-AT enable access to IPv4 only host from IPv6 host. IPv4 host is identified as SA46T global address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. SA46T-AT does not support access to IPv6 host from IPv4 only host. "DNS Extension for Autonomous Internet(AIP)", Diao Yuping, Diao Yongping, Ming Liao, 2015-07-01, With the reality of Internet, Autonomous Internet technology in this article constructs independent autonomous extensible domain name architecture and domain name hierarchy through current domain name architecture, provides independent root DNS server, inner/outer DNS resolution mechanism for each autonomous internet network system, and provides reformation and transition solution from current Internet to realize autonomy even in unilateral technical action. "Current issues with DNS Configuration Options for SLAAC", Fernando Gont, Pavel Simerda, Shucheng LIU, 2015-02-26, RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina Tsou, Simon Perreault, Jing Huang, 2013-09-16, An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. "An SNMP MIB extension to RFC3591 to manage optical interface parameters of "G.698.2 single channel" in DWDM applications", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Luyuan Fang, Gary Ratterree, 2015-07-06, This memo defines a module of the Management Information Base (MIB) used by Simple Network Management Protocol (SNMP) in TCP/IP- based internet. In particular, it defines objects for managing single channel optical interface parameters of DWDM applications, using the approach specified in G.698.2 [ITU.G698.2] . This interface, described in ITU-T G.872, G.709 and G.798, is one type of OTN multi- vendor Intra-Domain Interface (IaDI). This RFC is an extension of RFC3591 to support the optical parameters specified in ITU-T G.698.2 and application identifiers specified in ITU-T G.874.1 [ITU.G874.1]. Note that G.874.1 encompasses vendor-specific codes, which if used would make the interface a single vendor IaDI and could still be managed. The MIB module defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of the multi-vendor IaDI based on the Black Link approach. "Intra-CDN Provider CDNi Experiment", Ge Chen, Mian Li, Hongfei Xia, Bhumip Khasnabish, Jie Liang, 2015-01-27, In [RFC6770], the Inter-Affiliates CDN Interconnection use case is described. In this scenario, a large CDN Provider may have several autonomous or semi-autonomous subsidiaries that each operates on their own CDN. The CDN Provider needs to make these down-stream CDNs interoperate to provide a consistent service to its customers on the whole collective footprint. This document illustrates in details the CDNi experiment that has been carried out by China Telecom, and the lessons and experiences to CDNi standardization work. "Advanced Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2015-07-02, This draft describes advanced features for HTTP-CoAP proxy implementers. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. "MSML Package for the Media Control Channel Framework", Adnan Saleem, Steve Dunn, 2015-01-04, The Media Server Markup Language [RFC5707] is used to control and invoke many different types of services on IP media servers. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. This document describes the use of MSML [RFC5707] language used within the context of Media Control Channel Framework [RFC6230]. The use of MSML [RFC5707] is described here as a standalone package for use within and compliant with the Media Control Channel Framework [RFC6230]. "Exporting MIB Variables using the IPFIX Protocol", Paul Aitken, Benoit Claise, Colin McDowall, Jürgen Schönwälder, 2015-07-01, This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari, Kotikalapudi Sriram, 2015-07-02, RFC 6472 (i.e., BCP 172) recommends not using AS_SET and AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. "HyperText Markup Language Request For Comments Format", Joe Hildebrand, Paul Hoffman, 2015-07-06, 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. "PPSP Tracker Protocol-Extended Protocol", Rachel Huang, Rui Cruz, Mario Nunes, Joao Taveira, Deng Lingli, 2015-03-09, This document specifies an extension to the PPSP Tracker Protocol - Base Protocol, which complements the core messages of the protocol with Request-Response enhancements and usages, and with a new DISCONNECT Protocol-level message. These enhancements and usages are related with the exchange of meta information between trackers and peers, such as initial offer/request of participation in multimedia content streaming, content information, peer lists, reports of activity and status, and graceful disconnection from the network. The extension is retro-compatible with the PPSP-TP Base Protocol. "", Takuo Suganuma, Naoki Nakamura, Satoru Izumi, Hiroshi Tsunoda, Masahiro Matsuda, Kohei Ohta, 2015-01-22, This memo defines a portion of the Management Information Base (MIB), the GreenUsage-MIB, for use with network management protocols in the Internet community. In particular, the GreenUsage-MIB can be used to monitor the power-on/power-off status of electrical devices. "MAP Interoperability Testing Results", Xing Li, Congxiao Bao, Guoliang Han, Wojciech Dec, 2015-07-03, This document presents the testing results of a unified code accommodating encapsulation and translation modes of Mapping of Address and Port (MAP). Experiments show that the unified MAP CE is not only supporting MAP-E and MAP-T modes, but also backward compatible with AFTR of dual-stack lite and stateless/stateful NAT64. "RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Qian Wang, Wei Meng, Cui Wang, Mohamed Boucadair, 2015-06-03, This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Multicast-Prefixes-64 information, aiming to delivery the Multicast and Unicast IPv6 Prefixes to be used to build multicast and unicast IPv4-Embedded IPv6 addresses. this RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_v6_PREFIX64 option. "LISP Replication Engineering", Florin Coras, Albert Cabellos-Aparicio, Jordi Domingo-Pascual, Fabio Maino, Dino Farinacci, 2015-04-26, This document describes a method to build and optimize inter-domain LISP router distribution trees for locator-based unicast and multicast replication of EID-sourced multicast packets. "IBM's Shared Memory Communications over RDMA", Mike Fox, Constantinos Kassimis, Jerry Stevens, 2015-05-07, This document describes the IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides RDMA communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, transparent high availability and load balancing when redundant RDMA network paths are available, and it maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data. "LISP Control-Plane Multicast Signaling", Dino Farinacci, Maria Napierala, 2015-02-16, This document describes an alternate method to signal multicast tree building among xTRs in multicast capable LISP sites. This approach avoids the need to run a multicast routing protocol on the LISP overlay. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application", Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Zafar Ali, Ruediger Kunze, Dieter Beller, 2015-07-06, This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems or characterized by the Optical Transport Network (OTN) in accordance with the Interface Application Code approach defined in ITU-T Recommendation G.698.2.[ITU.G698.2], G.694.1.[ITU.G694.1] and its extensions. "Transparent SDH/SONET over Packet", Gert Manhoudt, Stephan Roullot, Kin Wong, 2015-01-26, This document describes the Transparent SDH/SONET over Packet (TSoP) mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or Synchronous Optical NETwork (SONET) bit-streams in a packet format, suitable for Pseudowire (PW) transport over a packet switched network (PSN). The key property of the TSoP method is that it transports the SDH/SONET client signal in its entirety through the PW, i.e., no use is made of any specific characteristic of the SONET/SDH signal format, other than its bit rate. The TSoP transparency includes transporting the timing properties of the SDH/SONET client signal. This ensures a maximum of transparency and a minimum of complexity, both in implementation and during operation. "Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing", Charles Perkins, 2015-05-30, The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. This document specifies an extension to AODVv2 (possibly useful with other reactive routing protocols) enabling intermediate nodes to shorten route discovery times. "Information Encoding for WSON with Impairments Validation", Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Domenico Siracusa, Andrea Zanardi, Federico Pederzolli, Young Lee, Fatai Zhang, 2015-03-09, Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) function might be required in Wavelength Switched Optical Networks (WSON) that already support RWA. This document defines proper encoding to support this operation. It goes in addition to the available impairment-free WSON encoding and it is fully compatible with it. As the information model, the encoding is independent from control plane architectures and protocol implementations. Its definitions can be used in related protocol extensions. "IRTF Research Group Guidelines and Procedures", Lars Eggert, 2015-02-17, The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to the Internet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined. This document obsoletes RFC2014. "Guidelines for Writing an IANA Considerations Section in RFCs", Michelle Cotton, Barry Leiba, Thomas Narten, 2014-11-10, Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values used in these fields do not have conflicting uses, and to promote interoperability, their allocation is often coordinated by a central authority. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given namespace prudently, IANA needs guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance given to IANA is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition, and obsoletes RFC 5226. "Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan, 2012-08-02, This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. "CDNI Footprint & Capabilities Advertisement Interface", Kevin Ma, Jan Seedorf, 2015-03-09, Content Distribution Network Interconnection (CDNI) is predicated on the ability of downstream CDNs (dCDNs) to handle end-user requests in a functionally equivalent manner to the upstream CDN (uCDN). The uCDN must be able to assess the ability of the dCDN to handle individual requests. The CDNI Footprint & Capabilities Advertisement interface (FCI) is provided for the advertisement of capabilities and the footprints to which they apply by the dCDN to the uCDN. This document describes an approach to implementing the CDNI FCI. "LLCPS", Pascal Urien, 2015-01-19, This document describes the support of the TLS protocol over the NFC (Near Field Communication) LLCP (Logical Link Control Protocol) layer, which is referred as LLCPS. The NFC peer to peer (P2P) protocol may be used by any application that needs communication between two devices at very small distances (a few centimeters). LLCPS enforces a strong security in NFC P2P exchanges, and may be deployed for many services, in the Internet of Things (IoT) ecosystem, such as payments, access control or ticketing operations. Applications secured by LLCPS are identified by the service name "urn:nfc:sn:tls:service". "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, 2015-06-23, 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. "The scrypt Password-Based Key Derivation Function", Colin Percival, Simon Josefsson, 2015-05-12, This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. "Multihoming in Homenet", Wassim Haddad, Damien Saucez, 2015-03-31, Multihoming becomes popular in residential and SME networks indicating the absolute necessity of fully supporting multihoming in Homenet. While the approach followed in Homenet is to delegate multihoming management to hosts, we propose to enable multihoming in Homenet by the mean of the infrastructure instead of the hosts. "Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)", Kenneth Murchison, 2015-01-12, This specification defines how the HTTP Prefer header field can be used by a WebDAV client to request that certain behaviors be employed by a server while constructing a response to a request. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Web Distributed Authoring and Versioning (WebDAV) mailing list at [1], which may be joined by sending a message with subject "subscribe" to [2]. This mailing list is archived at [3]. "Available Routing Constructs", Pascal Thubert, Patrice Bellagamba, 2015-01-22, This draft introduces the concept of ARC, a two-edged routing construct that forms its own fault isolation and recovery domain. The new paradigm can be leveraged to improve the network utilization and resiliency for unicast and multicast traffic in multiple environments, and is optimized to compute short reroute paths in case of breakages. "The application/stream+json Media Type", James Snell, 2012-10-11, This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. "Scenarios with Host Identification Complications", Mohamed Boucadair, David Binet, Sophie Durel, Bruno Chatras, Tirumaleswar Reddy, Brandon Williams, Behcet Sarikaya, Li Xue, Richard Wheeldon, 2015-04-07, This document describes a set of scenarios in which complications to identify which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows to identify what is common and then would help during the solution design phase. The document does not include any solution-specific discussion. "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", Samita Chakrabarti, Erik Nordmark, Pascal Thubert, Margaret Wasserman, 2015-02-27, IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined at a time when link-local multicast was as reliable and with the same network cost (send a packet on a yellow-coax Ethernet) as unicast and where the hosts were assumed to be always on and connected. Since 1996 we've seen a significant change with both an introduction of wireless networks and battery operated devices, which poses significant challenges for the old assumptions. We are also seeing datacenter networks where virtual machines are not always on and connected, and scaling of multicast can be challenging. This specification contains extensions to IPv6 Neighbor Discovery which remove most use of multicast and make sleeping hosts more efficient. The specification includes a default mixed mode where a link can have an arbitrary mix of hosts and/or routers - some implementing legacy Neighbor Discovery and some implementing the optimizations in this specification. The optimizations provide incremental benefits to hosts as soon as the first updated routers are deployed on a link. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 2015-06-10, This text documents 'P-Charge-Info', an existing private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. NOTE: This document has been in development since 2008 under the name draft-york-sipping-p-charge-info. This -05 document is identical to draft-york-sipping-p-charge-info-15 except for edits to the text to indicate this is now for the DISPATCH working group as the SIPPING working group no longer exists. "Scenario of IPv6 Transition Technologies Selection", Tianle Yang, Qiongfang Ma, 2015-07-05, Many IPv6 transition technologies has been proposed, such as Dual-Stack, 6rd and so on. An CPE may support some of them instead of only one. But the ISPs always support different kinds of transition technologies. So they must control all the CPEs to match the exact transition tech through the CPEs' management system or configuring them before issuing to the customers. "The eduroam architecture for network roaming", Klaas Wierenga, Stefan Winter, Tomasz Wolniewicz, 2015-03-09, This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, EAP and RADIUS that is used in eduroam provides a secure, scalable and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular the initial architectural and standards choices are described, along with the changes that were prompted by operational experience. "Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 2012-10-15, This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. "VRRP PIM Interoperability", Wei Zhou, 2015-06-12, This document introduces VRRP Aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. "SDP for the WebRTC", Suhas Nandakumar, Cullen Jennings, 2015-02-11, The Web Real-Time Communication [WebRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in [RFC3264]. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. "Pyramid Vector Quantization for Video Coding", Jean-Marc Valin, 2015-03-09, This proposes applying pyramid vector quantization (PVQ) to video coding. "CGA-TSIG/e: Algorithms for Secure DNS Authentication and Optional DNS Confidentiality", Hosnieh Rafiee, Christoph Meinel, 2015-05-08, This document describes a new mechanism for secure DNS authentication and a possible mechanism for DNS data confidentiality in various scenarios especially DNS resolvers. It also focuses on reducing human interaction during secure authentication and DNS message encryption. This document supports both IPv4 and IPv6 enabled networks. "Coding Tools for a Next Generation Video Codec", Timothy Terriberry, 2015-03-09, This document proposes a number of coding tools that could be incorporated into a next-generation video codec. "Observations on the experience and nature of Large Interim Meetings", Joel Jaeggli, Jari Arkko, 2013-01-14, Planning, particpipation and conclusions from the experience of participating in the IETF LIM activity on september 29th 2012. "Time Domain Lapped Transforms for Video Coding", Nathan Egge, Timothy Terriberry, 2015-03-09, This proposes the use of Time Domain Lapped Transforms (TDLT) as the transform step for video coding. "I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung Kwon, Hyojin Yoon, Sang Kim, 2013-05-03, Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. "The SignPuddle Standard for SignWriting Text", Stephen Slevinski, 2015-05-12, For concreteness, because the universal character set is not yet universal, and because an international standard for the internet community should be documented and stable, this I-D has been released with the intention of producing an RFC to document the character use and naming conventions of the SignWriting community on the Internet. The SignWriting Script is an international standard for writing sign languages by hand or with computers. From education to research, from entertainment to religion, SignWriting has proven useful because people are using it to write signed languages. The SignWriting Script has two major families: Block Printing for the reader and Handwriting for the writer. Formal SignWriting uses ASCII strings to name logographic signs. The mathematical names are explained with tokens and regular expression patterns. Symbol keys reference the symbols of the International SignWriting Alphabet 2010. Coordinates define X and Y number values for 2-dimensional placement. Signs are written in a spatial SignBox, where each symbol is positioned with a 2-dimension coordinate. For sorting, each sign can have an optional temporal sequence of symbols that is outside of the SignBox and the visible text. To create sentences, completed signs are written sequentially, interspersed with punctuation symbols. The query language of Formal SignWriting uses a lite markup, similar to FSW, to define a variety of searching possibilities. The spatial SignBox can be searched for symbols or ranges of symbols. For each symbol or range, the search can specify if the symbol only needs to be found somewhere in the SignBox, or if the symbol needs to be found near certain coordinates. The temporal sequence can be searched for starting symbols, written as a sequential list of symbols and ranges of symbols. When searching the temporal sequence, the search results will be limited to signs that start with a matching temporal sequence. Each query string is transformed into one or more regular expressions. The regular expressions are used to quickly search large amounts of data. SignWriting 2010 is the modern implementation and international specification of the SignWriting script for the internet community that includes TrueType Fonts and a compact JavaScript library. SignMaker is a standards based editor, utilizing HTML, CSS, JavaScript, SVG, TrueType Fonts, and PNG images. SignMaker can be used to create a private dictionary or to view dozens of sign language dictionaries derived from SignPuddle Online. For Unicode, there are several encodings possibilities. Formal SignWriting is UTF-8. The plane 15 encoding is isomorphic with Formal SignWriting strings, using 3 characters for each symbol, along with structural marker characters and number characters. The plane 16 encoding is focused on the symbols only, using 1 character for each symbol. The Unicode 8 specification uses 1 to 3 characters on plane 1 to name each symbol of the International SignWriting Alphabet 2010. Three appendices discuss additional topics to the standard. The first discusses the Modern SignWriting theory and example document, stable since January 12, 2012. The second discusses the symbol encoding of the International SignWriting Alphabet 2010. The third discusses the SignPuddle Standards: licences, infrastructure, and compatibility. This memo concretely defines a conceptual character encoding map for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "remoteStorage", Michiel de Jong, F. Kooman, 2015-06-18, This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. "Delay Limits and Multiplexing Policies to be employed with Tunneling Compressing and Multiplexing Traffic Flows", Mirko Suznjevic, Jose Saldana, 2015-06-13, This document contains recommendations to be taken into account when using methods which optimize bandwidth utilization through Tunneling Compressing and Multiplexing (TCM) traffic flows over a network path. Different multiplexing policies and implementation issues which are service and link specific are discussed. Additionally, this document describes policies which can be used for detecting, classifying, and choosing the network flows suitable for optimization by using TCM. Finally, recommendations of maximum tolerable delays to be added by optimization techniques are reported. Recommendations are presented only for network services for which such bandwidth optimization techniques are applicable (i.e., services with low payload to header size ratio, which will also be denoted as "small-packet flows"). "Requirements for Automated (Configuration) Management", Mohamed Boucadair, Christian Jacquenet, Luis Contreras, 2015-02-13, Given the ever-increasing complexity of the configuration tasks required for the dynamic provisioning of IP networks and services, this document aims at listing the requirements for an automated configuration management framework. "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, Victor Pascual, Anton Roman, Gonzalo Salgueiro, 2015-01-26, 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. "OAuth 2.0 Resource Set Registration", Thomas Hardjono, Eve Maler, Maciej Machulak, Domenico Catalano, 2015-04-04, This specification defines a resource set registration mechanism between an OAuth 2.0 authorization server and resource server. The resource server registers information about the semantics and discovery properties of its resources with the authorization server. "Self-published IP Geolocation Data", Erik Kline, Krzysztof Duleba, Zoltan Szamonek, 2013-07-28, This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline. "TRILL: Parent Selection in Distribution Trees", Howard Yang, Ayan Banerjee, Donald Eastlake, Radia Perlman, 2015-01-19, This document describes a protocol extension in TRILL IS-IS and a parent selection tiebreak algorithm in the calculation of distribution trees in TRILL. The proposal is to modify the current algorithm to improve the stability of the distribution trees when multiple equal cost parents are present. It also offers the capabilities of pinning down multi-destination traffic and re-shaping the distribution trees to improve the traffic load balancing. "Autonomous Extensible Internet with Network Address Multiplexing(AEIP NAM)", Diao Yuping, Diao Yongping, Ming Liao, 2015-01-28, The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP) with global network address and multiplexing local network address. This AEIP with Network Address Multiplexing(AEIP NAM) can realize autonomy and extensibility with minimal cost. "Coupled congestion control for RTP media", Michael Welzl, Safiqul Islam, Stein Gjessing, 2015-06-18, When multiple congestion controlled RTP sessions traverse the same network bottleneck, it can be beneficial to combine their controls such that the total on-the-wire behavior is improved. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm. "ARC vs. MRT", Pascal Thubert, Srinivasan Ramasubramanian, 2015-01-22, This draft compares the capabilities offered by the Available Routing Construct (ARC) and the Maximally Redundant Trees (MRT) techniques in order to support applicability statements. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Cyrus Daboo, Mike Douglass, 2015-01-06, This specification introduces a new iCalendar component which allows for consensus scheduling, that is, voting on a number of meeting or task alternatives. "Binding Obligations on User-Managed Access (UMA) Participants", Eve Maler, Thomas Hardjono, 2015-04-05, User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This document provides a contractual framework that defines the minimum obligations of parties that operate and use UMA-conforming software programs and services. The goal of this framework is to support end-to-end legal enforceability of the terms and conditions of access sharing relationships between authorizing and requesting sides that use UMA. The audience for this document includes technologists, legal professionals, and operators of UMA-conforming services. "Operational Issues Associated With Long IPv6 Header Chains", Warren Kumari, Joel Jaeggli, Ron Bonica, J. Linkova, 2015-06-16, This memo specifies requirements for IPv6 forwarders as they process packets with long header chains. It also provides guidance for application developers whose applications might rely on long headers chains. As background, this memo explains how many ASIC-based IPv6 forwarders process packets and why processing of packets with long header chains might be problematic. "Authentication Context Certificate Extension", Stefan Santesson, 2015-02-13, This document defines an extension to certificates according to [RFC5280]. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority who issued the certificate where this extension appears. This document also defines one data structure for inclusion in this extension that designed to hold information when the subject is authenticated using a SAML assertion [SAML]. "BGP Tunnel Encapsulation Attribute for UDP", Xiaohu Xu, Nischal Sheth, Rajiv Asati, 2015-02-12, This document specifies a new Border Gateway Protocol (BGP) Tunnel Type of User Datagram Protocol (UDP) tunnels. "Port Control Protocol (PCP) Flow Examples", Mohamed Boucadair, 2015-03-23, This document provides a set of examples to illustrate Port Control Protocol (PCP) operations. It is a companion document to the base PCP specification. "Ruoska Encoding", JPM, 2013-10-12, This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. "A YANG Data Model for LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-01-23, This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. "On the Validation of TCP Sequence Numbers", Fernando Gont, David Borman, 2015-03-26, When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated. "IPv6 Source/Destination Routing using IS-IS", Fred Baker, David Lamparter, 2015-07-03, This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix. "Differentiated Service Class Recommendations for LLN Traffic", Shitanshu Shah, Pascal Thubert, 2015-02-03, Differentiated services architecture is widely deployed in traditional networks. There exist well defined recommendations for the use of appropriate differentiated service classes for different types of traffic (eg. audio, video) in these networks. Per-Hop Behaviors are typically defined based on this recommendations. With emerging Low-power and Lossy Networks (LLNs), it is important to have similar defined differentiated services recommendations for LLN traffic. Defined recommendations are for LLN class of traffic exiting out of LLNs towards high-speed backbones, converged campus network and for the traffic in the reverse direction. "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE", Dhruv Dhody, Udayasree Palle, Ravi Singh, Rakesh Gandhi, 2015-06-17, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The stateful PCE extensions provide stateful control of Multi- Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for the case where PCC delegates control over one or more locally configured LSPs to the PCE. This document describes automatic bandwidth adjustment of such LSPs when employing an Active Stateful PCE. In one of the models described, PCC computes the bandwidth to be adjusted and informs the PCE whereas in the second model, PCC reports the real-time traffic to a PCE and the PCE computes the adjustment bandwidth. This document also describes automatic bandwidth adjustment for stateful PCE-initiated LSPs. "Simple VPN solution using Multi-point Security Association", Arifumi Yamaya, Takafumi Ohya, Tomohiro Yamagata, Satoru Matsushima, 2015-03-25, This document describes the over-lay network solution by utilizing dynamically established IPsec multi-point Security Association (SA) without individual connection. Multi-point SA technology provides the simplified mechanism of the Auto Discovery and Configuration function. This is applicable for any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4 and IPv6 over IPv6. "A Google Congestion Control Algorithm for Real-Time Communication", Stefan Holmer, Henrik Lundin, Gaetano Carlucci, Luca De Cicco, Saverio Mascolo, 2015-06-29, This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one delay- based and one loss-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that working group is rmcat@ietf.org. "CoAP Communication with Alternative Transports", Bill Silverajan, Teemu Savolainen, 2015-06-20, CoAP has been standardised as an application level REST-based protocol. A single CoAP message is typically encapsulated and transmitted using UDP or DTLS as transports. These transports are optimal solutions for CoAP use in IP-based constrained environments and nodes. However compelling motivation exists for allowing CoAP to operate with other transports and protocols. Examples are M2M communication in cellular networks using SMS, more suitable transport protocols for firewall/NAT traversal, end-to-end reliability and security such as TCP and TLS, or employing proxying and tunneling gateway techniques such as the WebSocket protocol. This draft examines the requirements for conveying CoAP messages to end points over such alternative transports. It also provides a new URI format for representing CoAP resources over alternative transports. "3GPP IMS Option for IKEv2", Sri Gundavelli, Jouni Korhonen, Florin Baboescu, Brian Weis, 2015-04-23, This document defines two new configuration attributes for Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network. "Virtual Machine Mobility Protocol for Overlay Networks", Behcet Sarikaya, Linda Dunbar, Bhumip Khasnabish, Frank Xia, 2015-03-09, This document specifies a virtual machine mobility protocol in data centers built with overlay-based network virtualization approach. The protocol is based on using NVA-NVE protocol to update ARP table or neighbor cache entries at the NVA and the source NVEs tunneling in-flight packets to the destination NVE after the virtual machine moves from source NVE to the destination NVE. "IS-IS Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, Alvaro Retana, Ning So, Vic Liu, Mehmet Toy, Lei Liu, 2015-03-08, This document presents a topology-transparent zone in a domain. A zone comprises a group of routers and a number of circuits connecting them. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone. "Syslog Format for NAT Logging", Zhonghua Chen, Cathy Zhou, Tina Tsou, Tom Taylor, 2014-01-24, NAT devices are required to log events like creation and deletion of translations and information about the resources the NAT is managing. The logs are required to identify an attacker or a host that was used to launch malicious attacks, and for various other purposes of accounting and management. Since there is no standard way of logging this information, different NAT devices behave differently. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 7011). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. "Multi-Upstream Interfaces IGMP/MLD Proxy", Hong-Ke Zhang, Thomas Schmidt, 2015-05-28, In this document, followed by the idea mentioned in [1] and subsequently updated in [2], an IGMP/MLD proxy with multiple upstream interfaces called MUIIMP is proposed and analyzed. The MUIIMP inherits the basic rule of the IGMP/MLD proxy but extends with multiple upstream interfaces. To avoid data redundancy, each upstream interface of an MUIIMP device MUST NOT send or subscribe to the same data simultaneously. "Benchmarking Neighbor Discovery", William Cerveny, Ron Bonica, 2015-01-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. "Autonomous Extensible Internet with Network Address Translation(AEIP NAT)", Diao Yongping, Ming Liao, Diao Yuping, 2015-03-26, The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP). It mainly adopts local network address based on per Autonomous IP network and uses bilateral dynamic NAT with global network address between Autonomous IP networks to solve IP address deficient problem. This AEIP with Network Address Translation(AEIP NAT) can realize autonomy and extensibility with minimal cost. "An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices", David Binet, Mohamed Boucadair, Vizdal Ales, Gang Chen, Nick Heatley, Ross Chandler, Dave Michaud, Diego Lopez, Walter Haeffner, 2015-03-25, This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network) with a special focus on IPv4 service continuity features. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. "I2RS overlay use case", fangwei hu, Bhumip Khasnabish, Chunming Wu, 2015-01-26, This document proposes an overlay network use case for interface to routing system (I2RS). The forwarding routers network is assumed to be an overlay structure. There are two types of forwarding routers: Edge Router(ER) and Core Routers(CR). Edge Router encapsulates format data based on the tunnel type, which are established among Edge Routers. Core Router would be very simple and cheap. CRs focus on the encapsulation data forwarding. In order to reduce the overall ER costs, the use of network virtualization is proposed in this document. "Augmented Password-Authenticated Key Exchange for Transport Layer Security (TLS)", SeongHan Shin, Kazukuni Kobara, 2015-01-28, This document describes an 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), and also provides resistance to server compromise (in the context of augmented PAKE security). Based on the AugPAKE protocol, this document also specifies a new password-only authentication handshake for Transport Layer Security (TLS) protocol. "KARP IS-IS security analysis", Uma Chunduri, Albert Tian, Wenhu Lu, 2015-07-06, This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. "LISP Based FlowMapping for Scaling NFV", sbarkai@gmail.com, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, 2015-05-01, This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance. "XML Schemas for Reverse DNS Management", Terry Manderson, 2015-06-22, This document defines an Extensible Markup Language (XML) Schema for Reverse DNS Management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" based system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an X.509 certificate mediated HTTPS transaction. "IPFIX Information Elements for logging NAT Events", Senthil Sivakumar, Reinaldo Penno, 2014-07-02, Network operators expect NAT devices to log events like creation and deletion of translations and information about the resources it is managing. The logs are essential in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices log the information using proprietary formats and hence it is difficult to expect a consistent behavior. The lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the formats for logging of NAT events. "Mounting YANG-Defined Information from Remote Datastores", Alex Clemm, Jan Medved, Eric Voit, 2015-04-10, This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. "ICANN Registry Interfaces", Gustavo Lozano, 2015-01-15, This document describes the interfaces provided by ICANN to Registry Operators in order to fulfill the requirements of Specification 2 and 3 of the New gTLD Base Agreement. The interface provided by ICANN to Data Escrow Agents in order to fulfill the requirements of Specification 2 of the New gTLD Base Agreement is also described in this document. "Design Recommendations for bfd to survive Planned Graceful restart", Palanivelan Appanasamy, 2015-05-01, Bidirectional Forwarding Detection (bfd) defined in RFC5880 is comprehensive and has sufficient mechanisms to overcome challenges in surviving Graceful Restart (Planned). However, implementations with architectural limitation were found to influence a BFD failure, in a process intensive environment.This memo outlines design options to overcome the challenges, within the existing bfd framework, in surviving planned GracefulRestart. "IMAP4 non-synchronizing literals", John Myers, Alexey Melnikov, 2015-03-09, The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. The former allows the alternate form of literals in all IMAP command. The latter is the same as LITERAL+, but disallow the alternate form in IMAP APPEND, unless they are 4096 bytes or less. "Implementation Experience of Identifier-Locator Network Protocol for IPv6 (ILNPv6)", Jun Bi, You Wang, Kai Gao, 2015-05-09, The Identifier-Locator Network Protocol (ILNP) defines an evolutionary enhancement to IP to address multi-homing, mobility as well as other issues. This document provides experience of implementing ILNPv6 which is a specific engineering instance of ILNP based on IPv6. This document describes the problems arisen and our choices to solve the issues which may be helpful to others in implementing the protocol. "Signing HTTP Messages", Mark Cavage, Manu Sporny, 2015-01-19, When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature. "Session Initiation Protocol (SIP) Instance ID usage by the Open Mobile Alliance Push-to-talk over Cellular", Andrew Allen, Alan Soloway, 2015-02-18, This document describes how the SIP Instance ID as defined in RFC 5626 [1] is used by the Open Mobile Alliance (OMA), for Push-to-talk over Cellular (PoC) and Push-to-Communicate for Public Safety (PCPS) and addresses security concerns with use of the SIP instance ID in non-register requests and responses. This document updates RFC 7255 [2] to allow the use of the International Mobile Equipment Identity (IMEI) as an instance ID in the Contact header field of non-register requests and responses by the OMA PoC and PCPS enablers for the purposes described in this document. "A Common Operational Problem in DNS Servers - Failure To Respond.", Mark Andrews, 2015-05-18, The DNS is a query / response protocol. Failure to respond to queries causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common classes of queries that some servers fail to respond too. This document also suggests procedures for TLD and other similar zone operators to apply to reduce / eliminate the problem. "Connectivity Provisioning Negotiation Protocol (CPNP)", Mohamed Boucadair, Christian Jacquenet, Dacheng Zhang, Panos Georgatsos, 2015-03-23, This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used to facilitate the dynamic negotiation of service parameters. CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks (CDN) footprint, etc. CPNP can be extended with new Information Elements. "SA46T Prefix Resolution (SA46T-PR)", Naoki Matsuhira, 2015-01-22, This document specifies SA46T Prefix Resolution (SA46T-PR) specification. SA46T-PR is almost same as SA46T, however method of generation of outer IPv6 address is different. SA46T is backbone network based approach, however SA46T-PR is stub network based approch. "SA46T Prefix Translator (SA46T-PT)", Naoki Matsuhira, 2015-01-22, This document specifies SA46T Prefix Translator (SA46T-PT) specification. SA46T-PT expand IPv4 network plane by connecting SA46T domain and SA46T-PR domain. SA46T-PT translate prefix part of SA46T address and SA46T-PR address both are IPv6 address. SA46T-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. "Seamless Bidirectional Forwarding Detection (S-BFD) for Segment Routing", Nobo Akiya, Carlos Pignataro, Nagendra Kumar, 2015-02-23, This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for the Segment Routing environment. "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Phillip Hallam-Baker, 2015-07-06, Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. "GDOI Protocol Support for IEC 62351 Security Services", Brian Weis, Maik Seewald, Herb Falk, 2015-06-01, The IEC 61850 power utility automation family of standards describe methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo defines GDOI payloads to support those security protocols. "NVGRE-EXT: Network Virtualization using Generic Routing Encapsulation Extensions", Murari Sridharan, Yu-Shun Wang, Pankaj Garg, Praveen Balasubramanian, 2015-06-23, This document describes the usage of "Network Virtualization using Generic Routing Encapsulation (NVGRE)" Extensions (NVGRE-EXT). The focus of this document is on specifying the control plane operations done using NVGRE packets. "PCP for SIP Deployments in Managed Networks", Mohamed Boucadair, Parthasarathi Ravindran, 2015-03-23, This document discusses how PCP (Port Control Protocol) can be used in SIP deployments in managed networks. This document applies for both IPv4 and IPv6. "BGP vector routing.", Robert Raszuk, Keyur Patel, Burjiz Pithawala, Ali Sajassi, eric.osborne@level3.com, Luay Jalil, Jim Uttaro, 2015-04-26, Network architectures have begun to shift from pure destination based routing to service aware routing. Operator requirements in this space include forcing traffic through particular service nodes (e.g. firewall, NAT) or segments. This document proposes an enhancement to BGP to accommodate these new requirements. This document proposes a pure control plane solution which allows traffic to be routed via an ordered set of transit points (links, nodes, or services) on the way to traffic's destination, with no change in the forwarding plane. This approach is in contrast to other proposal in this space which provide similar capabilities via modifications to the forwarding plane. "CoAP Management Interface", Peter Van der Stok, Andy Bierman, Jürgen Schönwälder, Anuj Sehgal, 2015-07-06, This document describes a network management interface for constrained devices, called CoMI. CoMI is an adaptation of the RESTCONF protocol for use in constrained devices and networks. It is designed to reduce the message sizes, server code size, and application development complexity. The Constrained Application Protocol (CoAP) is used to access management data resources specified in YANG, or SMIv2 converted to YANG. The payload of the CoMI message is encoded in Concise Binary Object Representation (CBOR). "Multicast Support for Mapping of Address and Port Protocol and Light Weight 4over6", Behcet Sarikaya, Hui Ji, 2015-06-08, This memo specifies multicast component for MAP and Light Weight 4over6 so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. The solution developed is based on translation. In the Translation Multicast solution for MAP (MAP-E and MAP-T) and lw4o6, IGMP messages are translated into MLD messages and sent to the network in IPv6. MAP Border Relay/lwAFTR does the reverse translation and joins IPv4 multicast group for the hosts. Border Relay/lwAFTR as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs/lwB4s receive multicast data, translate it back to IPv4 and transmit to the hosts. "Support for Icalendar Relationships", Mike Douglass, 2015-01-14, 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. "Energy Aware Control Approach for QoS in heterogeneous packet access networks", DH, Nico Bayer, Christoph Lange, 2015-01-20, This document describes an approach to enhance user perceived service quality by control protocols following potential network performance impairments in case of energy aware network operation. "Tunnel Congestion Feedback", Xinpeng Wei, Lei Zhu, Lingli Deng, Bob Briscoe, 2015-06-30, This document describes a mechanism to calculate congestion of a tunnel segment based on RFC 6040 recommendations, and a feedback protocol by which to send the measured congestion of the tunnel from egress to ingress . A basic model for measuring tunnel congestion and feedback is described, and a protocol for carrying the feedback data is outlined. "Draft and Release using Internet Email", Alexey Melnikov, 2015-06-23, This document describes a procedure for when an Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more authorizing users authorize release of the message by adding the MMHS- Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and review signatures. "Path Computation Element (PCE) Discovery using Domain Name System(DNS)", Wenson Wu, Dhruv Dhody, Daniel King, Diego Lopez, Jeff Tantsura, 2015-04-29, Discovery of the Path Computation Element (PCE) within an IGP area or routing domain is possible using OSPF and IS-IS IGP discovery. However, it has been established that in certain deployment scenarios PCEs may not wish, or be able to participate within the IGP process. In those scenarios, it is beneficial for the Path Computation Client (PCC) (or other PCE) to discover PCEs via an alternative mechanism to using an IGP discovery. This document specifies the requirements, use cases, procedures and extensions to support PCE discovery along with certain relevant information type and capability discovery via DNS. "LSP-DB Synchronization between Stateful PCEs", Udayasree Palle, Dhruv Dhody, Xian Zhang, 2015-01-20, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. [STATEFUL-PCE] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP and maintaining of these LSPs at the stateful PCE. This document describes the mechanisms of LSP Database (LSP-DB) synchronization between stateful PCEs. "IP Flow Performance Measurement Framework", Mach Chen, Lianshu Zheng, Greg Mirsky, Giuseppe Fioccola, 2015-07-06, This document specifies a measurement method, the IP flow performance measurement (IPFPM). With IPFPM, data packets are marked into different blocks of markers by changing one or more bits of packets. No additional delimiting packet is needed and the performance is measured in-service and in-band without the insertion of additional traffic. "Time Capability in NETCONF", Tal Mizrahi, Yoram Moses, 2015-05-07, This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times, and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. "Stateless user-plane architecture for virtualized EPC (vEPC)", Satoru Matsushima, Ryuji Wakikawa, 2015-03-09, We envision a new mobile architecture for the future Evolved Packet Core (EPC). The new architecture is designed to support the virtualization scheme called NFV (Network Function Virtualization). In our architecture, the user plane of EPC is decoupled from the control-plane and uses routing information to forward packets of mobile nodes. Although the EPC control plane will run on hypervisor, our proposal does not modify the signaling of the EPC control plane. The benefits of our architecture are 1) scalability, 2) flexibility and 3) Manageability. How to run the EPC control plane on NFV is out of our focus in this document. "An IPv6 Distributed Client Mobility Management approach using existing mechanisms", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, 2015-03-05, The use of centralized mobility management approaches -- such as Mobile IPv6 -- poses some difficulties to operators of current and future networks, due to the expected large number of mobile users and their exigent demands. All this has triggered the need for distributed mobility management alternatives, that alleviate operators' concerns allowing for cheaper and more efficient network deployments. This draft describes a possible way of achieving a distributed mobility behavior with Client Mobile IP, based on Mobile IPv6 and the use of Cryptographic Generated Addresses. "CoAP over WebSockets", Teemu Savolainen, Klaus Hartke, Bill Silverajan, 2015-03-31, This document specifies how to retrieve and update CoAP resources using CoAP requests and responses over the WebSocket Protocol. "MPLS Domain Wide Labels", Robert Raszuk, 2015-04-27, This document describes a mechanism of using concept of Domain Wide MPLS Labels in parallel with any of the existing deployments using other label distribution and allocation methods where multi protocol label switching paradigm is used for transport. Specifically it defines a new type of context label which can be used to differentiate lookup tables when using Domain Wide transport Labels from other downstream or upstream assigned transport labels. The end result is creation of clean new label space in data plane allowing very easy and smooth migration to the number of applications choosing to use Domain Wide MPLS Labels. "Jitter Consideration for Reactive Protocols in Mobile Ad Hoc Networks (MANETs)", Jiazi Yi, Juan Fuertes, Thomas Clausen, 2015-01-09, This document provides recommendations for jittering (randomly timing) of routing control message transmission, especially route request dissemination, in reactive protocols of Mobile Ad Hoc Networks, to reduce the probability of collisions, decrease routing overhead, and help finding the optimum paths in the network. "Use case analysis for supporting flow mobility in DMM", gomjae@dcn.ssu.ac.kr, Young-Han Kim, 2015-03-09, Distributed Mobility Management (DMM) allows network traffic to distribute among multiple mobility anchors which have mobility functions to solve the existing problems in current centralized mobility protocols. There are many DMM approaches extending network-based mobility protocols (e.g. Proxy Mobile IPv6). In Proxy Mobile IPv6 (PMIPv6), they allow a mobile node to connect to PMIPv6 domain through different physical interfaces. In this reason, flow mobility that enables movement between physical interfaces of mobile node is proposed. In this document, we present some use cases to support flow mobility in DMM domain and analyze some problems. These use cases are based on scenarios of flow mobility in PMIPv6. In these scenarios, a multi-interface mobile node connects to different distributed mobility access points and move specific flows from one interface to another. These use cases have common issues which will be analyzed in detail. "Multiple IPv6 Prefixes: Background and Considerations", Bing Liu, Sheng Jiang, Yang Bo, 2015-03-25, This document describes several typical multiple prefixes use cases, and discusses that running multiple IPv6 prefixes/addresses in one network/host should be common proactice that administrators need to adapt. "Using ICN in disaster scenarios", Jan Seedorf, Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2015-03-03, Information Centric Networking is a new paradigm where the network provides users with named content, instead of communication channels between hosts. This document outlines some research directions for Information Centric Networking (ICN) with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. "ALTO Topology Extensions: Node-Link Graphs", Greg Bernstein, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, 2015-03-09, The Application-Layer Traffic Optimization (ALTO) Service has defined network and cost maps to provide basic network information. In this document, we discuss designs to provide abstracted (node-link) graph representations of network topology. "Private Autonomous System (AS) Removal Requirements", Jon Mitchell, Dhananjaya Rao, Robert Raszuk, 2015-04-20, This document specifies operator's requirements for implementations that remove Private Use Autonomous System (AS) numbers from the AS path of routes sent to external Border Gateway Protocol (BGP) peers. "A Framework of Multipath Transport System Based on Application-Level Relay (MPTS-AR)", Lei Weimin, Wei Zhang, Shaowei Liu, 2015-01-21, Multipath transport is an important way to improve the efficiency of data delivery. This document defines a multipath transport system framework in which application-level relays are deployed to provide the conditions to enable multiple paths between source and destination. In the proposed framework, endpoints are allowed to use multiple paths, including the default IP path and relay paths, to transport data in a single session. A relay path may via one or more application-level relays which provide application-level relay services for endpoints. This framework defines three kinds of logical entities including user agent, relay server and relay controller. Relay server provides relay service for user agents based on a local path-table. Relay controller manages relay servers and relay paths. User agent maintains multiple end-to-end paths which include a default path and multiple relay paths. The framework also defines a relay service control protocol named OpenPath protocol in control plane to manage relay servers and relay paths, and a profile of multipath transport protocol suite in data plane to facilitate multipath data transport. The multipath transport system framework can support various applications including applications requiring timely delivery of real-time data such as streaming media, and applications requiring ordered reliable delivery of stream of data such as file transfer. "Multipath Message Transport Protocol Based on Application-level Relay (MPMTP-AR)", Lei Weimin, Shaowei Liu, Wei Zhang, 2015-01-21, Multipath transmission is an important way to improve the quality of service for message transport. This document defines a multipath message transmission protocol, which is a special application profile of multipath transport protocol suite defined in Multipath Transport System Based on Application-level Relay (MPTS-AR). Apart from behaviors of user agent defined in MPTS-AR, user agent should be also responsible for message reliable transmission,including connective session establishment, sequenced deliver, select acknowledgement, retransmission, recombination and congestion avoidance, etc. This document describes those new or changed behaviors, and expands the MPTP format to meet them.Moreover this document illustrates the details of multipath transmission mechanism reference to the reliable transmission characteristics. "Multipath Real-Time Transport Protocol Based on Application-Level Relay (MPRTP-AR)", Lei Weimin, Wei Zhang, Shaowei Liu, 2015-01-21, Currently, most multimedia applications utilize a combination of real-time transport protocol (RTP) and user datagram protocol (UDP). Application programs at the source end format payload data into RTP packets using RTP specifications and dispatch them using unreliable UDP along a single path. Multipath transport is an important way to improve the efficiency of data delivery. In order to apply the framework of multipath transport system based on application-level relay (MPTS-AR) to RTP-based multimedia applications, this document defines a multipath real-time transport protocol based on application-level relay (MPRTP-AR), which is a concrete application-specific multipath transport protocol (MPTP). Packet formats and packet types of MPRTP-AR follow the common rules specified in MPTP profile. Based on MPRTP-AR, RTP-based multimedia applications can make full use of the advantages brought by MPTS-AR. "Recommendations for Prefix Binding in the Softwire DS-Lite Context", Suresh Vinapamula, Mohamed Boucadair, 2015-07-01, This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues. "Remote APDU Call Secure (RACS)", Pascal Urien, 2015-06-26, This document describes the Remote APDU Call Protocol Secure (RACS) protocol, dedicated to Grid of Secure Elements (GoSE). These servers host Secure Elements (SE), i.e. tamper resistant chips offering secure storage and cryptographic resources. Secure Elements are microcontrollers whose chip area is about 25mm2; they deliver trusted computing services in constrained environments. RACS supports commands for GoSE inventory and data exchange with secure elements. It is designed according to the representational State Transfer (REST) architecture. RACS resources are identified by dedicated URIs. An HTTP interface is also supported. "Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol", Nicholas Wilson, 2013-10-07, The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. "Directory-Based Information Services: Mapping Objects", Mark Bannister, 2015-01-06, This is one of several documents that describe the components within Directory-Based Information Services (DBIS). DBIS provides a framework for the representation of data relating to TCP/IP and the UNIX system within [X.500] entries that have previously been stored in the Network Information Service [NIS]; so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. The intention of DBIS is to extend, and thereby replace both NIS and the experimental protocol for using LDAP as a Network Information Service (RFC2307), which have both achieved widespread adoption. DBIS consists of an LDAP schema, naming conventions and protocols to describe its use by DUAs requiring network service information. Client/server communication and server-side operations are entirely contained within the domain of LDAP. Key aspects of DBIS and improvements over RFC2307 are: - Schema is backwards compatible with NIS, including case sensitivity of key names. - Standardisation of mapping information to increase portability of DUA implementations and to reduce duplication of client configuration data. - Features added to increase flexibility in large complex environments: o Maps may be joined from data located in different areas of the Directory Information Tree (DIT). o Groups of DUAs may have variances in their data depending upon their host netgroup membership. - Modular design to allow separate parts of the system to be replaced, improved or augmented separately in the future. - Support added for automounter maps [draft-bannister-dbis- automounter-00]. This document describes mapping objects used by DBIS to locate and transform service information stored within the DIT. "Directory-Based Information Services: Netgroups and Netservices", Mark Bannister, 2015-03-23, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support netgroup and netservice databases. A netgroup database schema SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. A netgroup database represents groups of hosts, users and domains. A netservice database schema is a new extension to netgroups that allows administrators to describe services or configuration options for a user or system based upon their netgroup membership. This document describes configuration maps [draft-bannister-dbis- mapping-00] for netgroup and netservice databases, and database entries referenced by those maps. "Directory-Based Information Services: Users and Groups", Mark Bannister, 2015-03-23, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support passwd and group databases. The passwd and group database schemas SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. A passwd database represents user login accounts on UNIX and UNIX- like systems and a group database represents user groups. This document describes configuration maps [draft-bannister-dbis- mapping-00] for passwd and group databases, and database entries referenced by those maps. Overlays may optionally be used to help reduce the complexity of merging multiple DBIS domains in large environments by permitting groups of hosts to have variations in their UIDs, GIDs, home directories and login shells. "Directory-Based Information Services: Hosts, Networks and Services", Mark Bannister, 2015-02-25, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support hosts, networks, netmasks, protocols, rpc and services databases. The database schemas SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. A hosts database maps hostnames to IP addresses, networks map network names to network numbers, netmasks map network numbers to netmasks, protocols map network protocol names to protocol numbers, rpc maps Remote Procedure Call [RFC1057] program names to RPC program numbers and services map network service names to port numbers and protocols. This document describes configuration maps [draft-bannister-dbis- mapping-00] for hosts, networks, protocols, rpc and services, and database entries referenced by those maps. "Directory-Based Information Services: Devices", Mark Bannister, 2015-02-25, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support ethers and bootparams databases. The database schemas SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. An ethers database maps 48-bit Ethernet addresses to IP addresses or host names, and bootparams maps hosts to boot-time kernel parameters. This document describes LDAP object classes and attributes required to extend hosts entries [draft-bannister-dbis-hosts-00] to support parameters for ethers and bootparams maps. "Directory-Based Information Services: Automounter", Mark Bannister, 2015-01-05, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support the automount database. The automount database schema SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4510]. An automount database contains information about file system mount- points that are to be mapped by the automounter. This document describes configuration maps [draft-bannister-dbis- mapping-00] for the automount database, and database entries referenced by those maps. "Metadata Query Protocol", Ian Young, 2015-04-24, This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. "Using ZRTP to Secure WebRTC", Alan Johnston, Philip Zimmermann, Jon Callas, Travis Cross, John Yoakum, 2015-07-06, WebRTC, Web Real-Time Communications, is a set of protocols and APIs used to enable web developers to add real-time communications into their web pages and applications with a few lines of JavaScript. WebRTC media flows are encrypted and authenticated by SRTP, the Secure Real-time Transport Protocol while the key agreement is provided by DTLS-SRTP, Datagram Transport Layer Security for Secure Real-time Transport Protocol. However, without some third party identity service or certificate authority, WebRTC media flows have no protection against a man-in-the-middle (MitM) attack. ZRTP, Media Path Key Agreement for Unicast Secure RTP, RFC 6189, does provide protection against MitM attackers using key continuity augmented with a Short Authentication String (SAS). This specification describes how ZRTP can be used over the WebRTC data channel to provide MitM protection for WebRTC media flows keyed using DTLS-SRTP. This provides users protection against MitM attackers without requiring browsers to support ZRTP or users to download a plugin or extension to implement ZRTP. "Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)", Russ Housley, 2015-03-31, This document specifies the conventions for using the Merkle Tree Signatures (MTS) digital signature algorithm with the Cryptographic Message Syntax (CMS). The MTS algorithm is one form of hash-based digital signature. "HIEP: HTB Internet E-wallet Protocol", Tian Guorong, Shen Jun, Curtis Yang, 2015-04-16, This document describes an online-paying method that realizes the paying addressing on the basis of HTTP protocol. It is for the purpose to setup a normative and safe E-paying system standard, and specify the definition of E-paying. And in this version, we changed the identifier of this e-payment protocol into to replace the previous one because it COULD be typed from the existed code. "CoAP option for no server-response", Abhijan Bhattacharyya, Soma Bandyopadhyay, Arpan Pal, 2015-06-03, There can be M2M scenarios where responses from server against requests from client might be considered redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while simultaneously updating a bulk of resources or updating a resource with a very high frequency. CoAP already provides a non-confirmable (NON) mode of message exchange where the server end-point does not respond with ACK. However, obeying the request/response semantics, the server end-point responds back with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option for CoAP called 'No-Response'. Using this option the client explicitly tells the server to suppress responses against the particular request. This option also provides granular control to enable suppression of a particular class or a combination of response-classes. This option may be effective for both unicast and multicast requests. Present draft also discusses few exemplary applications which benefit from this option. "TRILL: Multi-Topology", Donald Eastlake, Mingui Zhang, Ayan Banerjee, Vishwas Manral, 2015-07-02, This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. It updates RFC 6325 and RFC 7177. "The TCP Service Number Option (SNO)", Joseph Touch, 2015-03-09, This document specifies a TCP option for service numbers. The current SYN destination port is used both to indicate the desired service and as a connection demultiplexing field. This option separates those two functions, retaining the current destination port solely for demultiplexing and indicating the service separately in a service number option (SNO). By decoupling these two functions, SNO allows a larger number of concurrent connections for a single service, as might be useful between fixed addresses of proxies. "NFS Protocol Extension: Retrospect and Prospect", David Noveck, 2015-03-08, This document surveys the processes by which the NFS protocol has been extended in the past, including all of the NFS major and minor versions. A particular focus is on how the minor versioning model of NFSv4 has worked and what might be done to enhance version management within NFSv4. The work already done in the new NFSv4 version management document is summarized, and there is a discussion of further issues the working group will need to address in moving that work forward. "IPv6 Path MTU Interactions With Link Adaptation", Fred Templin, 2015-02-27, IPv6 intentionally deprecates fragmentation by routers in the network. Instead, links with restricting Maximum Transmission Units (MTUs) must either drop each too-large packet and return an ICMPv6 Packet Too Big (PTB) message or perform link-specific fragmentation and reassembly (also known as "link adaptation") at a layer below IPv6. This latter category of links is often performance-challenged to accommodate steady-state link adaptation. This document therefore proposes an update to the base IPv6 specification to better accommodate links that require link-specific adaptation. "Suspenders: A Fail-safe Mechanism for the RPKI", Stephen Kent, David Mandelberg, 2015-04-29, The Resource Public Key Infrastructure (RPKI) is an authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. The certification authorities (CAs) in the RPKI issue certificates to match their allocation of INRs. These entities are trusted to issue certificates that accurately reflect the allocation state of resources as per their databases. However, there is some risk that a CA will make inappropriate changes to the RPKI, either accidentally or deliberately (e.g., as a result of some form of "government mandate"). The mechanisms described below, and referred to as "Suspenders" are intended to address this risk. Suspenders enables an INR holder to publish information about changes to objects it signs and publishes in the RPKI repository system. This information is made available via a file that is external to the RPKI repository, so that Relying Parties (RPs) can detect erroneous or malicious changes related to these objects. RPs can then decide, individually, whether to accept changes that are not corroborated by independent assertions by INR holders, or to revert to previously verified RPKI data. "PCE support for Domain Diversity", Dhruv Dhody, Qin Wu, Udayasree Palle, Xian Zhang, 2015-04-20, The Path Computation Element (PCE) may be used for computing path for services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. Path computation should facilitate the selection of paths with domain diversity. This document examines the existing mechanisms to do so and further propose some extensions to Path Computation Element Protocol (PCEP). "Requirements for Service Function Chaining (SFC)", Mohamed Boucadair, Christian Jacquenet, Yuanlong Jiang, Ron Parker, Kengo, 2015-02-13, This document identifies the requirements for the Service Function Chaining (SFC). "GDOI GROUPKEY-PUSH Acknowledgement Message", Brian Weis, Umesh Mangla, Nilesh Maheshwari, Thomas Karl, 2015-03-09, The Group Domain of Interpretation (RFC 6407) includes the ability for a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request the GM devices to return an acknowledgement of receipt of its rekey message, and specifies the acknowledgement method. "Application-Initiated Flow High Availability Awareness through PCP", Suresh Vinapamula, Senthil Sivakumar, Mohamed Boucadair, Tirumaleswar Reddy, 2015-06-23, This document specifies a mechanism for a host to signal via Port Control Protocol (PCP) which connections should be protected against network failures. These connections will be elected to be subject to high availability mechanisms enabled at the network side. This approach assumes that applications/users have more visibility about sensitive connections rather than any heuristic that can be enabled at the network side to guess which connections should be check-pointed. "Use case for a scalable and topology aware MPLS data plane monitoring system", Ruediger Geib, Clarence Filsfils, Carlos Pignataro, Nagendra Kumar, 2015-07-03, This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. Compared with legacy MPLS ping and path trace, MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. "OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels", Anton Smirnov, Alvaro Retana, Michael Barnes, 2015-04-08, When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This is solved by advertising cross-address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. "Ideas for a Next Generation of the Reliable Server Pooling Framework", Thomas Dreibholz, 2015-07-05, This document collects some idea for a next generation of the Reliable Server Pooling framework. "What's the Impact of Virtualization on Application-Layer Traffic Optimization (ALTO)?", Qiao Fu, Zehn Cao, Haibin Song, 2015-06-09, This documentation presents a use case of Application-Layer Traffic Optimization (ALTO) with the emergence of Network Function Virtualization (NFV). The Application-Layer Traffic Optimization (ALTO) Service provides network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The emerging NFV, which is currently being in progress in ETSI NFV, leverages standard IT virtualisation technology to consolidate many network equipment types onto industry standard high-volume servers, switches, and storage. The use case presented in this document discusses the impact of virtualization on the ALTO protocol. An architecture is proposed for the interface between NFV MANO and ALTO server. And possible end point property extention is also discussed for such usecase. "Segment Routing interoperability with LDP", Clarence Filsfils, Stefano Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Igor Milojevic, Rob Shakir, Saku Ytti, Wim Henderickx, Jeff Tantsura, Edward Crabbe, 2015-03-09, A Segment Routing (SR) 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 to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. "Transmission Control Protocol Specification", Wesley Eddy, 2015-02-06, This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. "ALTO Traffic Engineering Cost Metrics", Wenson Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2015-04-29, 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 defined only a single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). In this document, we define eleven Cost Metrics, derived from OSPF-TE and ISIS-TE, to measure network delay, jitter, packet loss, hop count, and bandwidth. The metrics defined in this document provide a relatively comprehensive set of Cost Metrics for ALTO focusing on traffic engineering (TE). Additional Cost Metrics such as financial cost metrics may be defined in other documents. "The "safe" HTTP Preference", mnot, 2015-02-12, This specification defines a "safe" preference for HTTP requests, expressing a desire to avoid "objectionable" content. "Pronouncing and Using Chinese Personal Names", Hui Deng, Zhen Cao, Paul Hoffman, 2015-04-23, This document gives general rules for how to pronounce Mandarin Chinese names in conversation, and how to determine which name is someone's surname. It also covers some other related topics about Chinese names. The intent is to allow IETF participants who are not familiar with Chinese to communicate better with Chinese participants. "Routing Optimization with SDN", yangun@dcn.ssu.ac.kr, gomjae@dcn.ssu.ac.kr, Young-Han Kim, 2015-07-06, DMM is a mobility protocol which has mobility functions to solve the existing problems in the current centralized ones. However, when a mobile node moves to another anchor, the previous flow is forwarded by the previous router. For this reason, the routing optimization could be an issue. This draft proposes a routing optimization method in distributed anchor architecture. In this draft, we applied the SDN concept to DMM architecture for routing optimization. "ISIS Auto-Configuration", Bing Liu, Bruno Decraene, Ian Farrer, Mikael Abrahamsson, 2015-06-19, This document specifies an IS-IS auto-configuration technology. The key mechanisms of this technology are IS-IS NET (Network Entity Title) self-generation, duplication detection and duplication resolution. This technology fits the environment where plug-and-play is expected. "PID Property Extension for ALTO Protocol", Wendy Roome, Yang Yang, 2015-01-23, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by defining PID-based properties in much the same way that the original ALTO Protocol defined endpoint-based properties. "Trust models of the Web PKI", Inigo Barreira, Bruce Morton, 2015-04-29, This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust. "Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen, Autumn Liu, Fengman Xu, Mehmet Toy, Vic Liu, 2015-02-28, This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). "The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs", Quintin Zhao, Zhenbin Li, Zekung Ke, Luyuan Fang, Chao Zhou, Telus Communications, 2015-07-06, In certain networks deployment scenarios, service providers would like to keep all the existing MPLS functionalities in both MPLS and GMPLS network while removing the complexity of existing signaling protocols such as LDP and RSVP-TE. In this document, we propose to use the PCE as a central controller so that LSP can be calculated/ signaled/initiated/downloaded/managed through a centralized PCE server to each network devices along the LSP path while leveraging the existing PCE technologies as much as possible. This draft describes the use cases for using the PCE as the central controller where LSPs are calculated/setup/initiated/downloaded/ maintained through extending the current PCE architectures and extending the PCEP. "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)", Gavin Brown, 2015-02-17, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. "Inter-domain SLA Exchange Implementation Report", Shitanshu Shah, Keyur Patel, 2015-02-12, 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. "Sender Constrained JWT for OAuth 2.0", Nat Sakimura, Kepeng Li, 2015-06-28, This discussion document describes a method to indicate a sender constraint within JWT. It could potentially be incorporated into POPS spec [POPS]. "Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol", Walter H., 2013-11-25, This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. "Special-Use Domain Names of Peer-to-Peer Systems", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, Leif Ryge, 2015-01-24, This document registers a set of Special-Use Domain Names for use with Peer-to-Peer (P2P) systems, as per RFC6761. "Extensions to WHois service to allow query on email identities", pradeep xplorer, 2015-02-21, This document describes the need for a WHois email address service similar to the internet domainname WHois service. Theres a need for a registered email address as opposed to non-registered email address to fight internet SPAM, as well as encouraging email use for personal, commercial and legal and all kinds of purposes.An internet user can have multiple email identities. This service implementation would also help deliver a Single SignON solution for WWW services. "Possible Attack on Cryptographically Generated Addresses (CGA)", Hosnieh Rafiee, Christoph Meinel, 2015-05-08, This document describes the possible attacks with the use of Cryptographically Generated Addresses. "Information as a bird with wings that flies and hits the user device screen as Icons", pradeep xplorer, 2015-04-17, The document proposes a WWW as an intelligent being that delivers information to users. This can be combined with a Single SignON solution for the WWW seen as one Giant computer. Imagine having a handy device and you travel to Bangkok and in the morning when you authenticate to WWW, your WWW navigation screen shows you very useful Icons that can create a better experience for you. "Confidential DNS", Wouter Wijngaards, Glen Wiley, 2015-03-06, This document offers opportunistic encryption to provide privacy for DNS queries and responses. "Universally Traceable Identifier (UTID)", huangng@gmail.com, 2015-05-19, A Universally Traceable Identifier (UTID) is a compact string of characters for identifying an abstract or physical object. A unique feature of UTID is that it contains two types of forwarding messages to achieve traceability. UTIDs are designed specially for Identifier Tracing Protocol (ITDP) [I-D-IDTP]. This document defines the generic syntax of UTID, a generative grammar for UTID, and the guidelines for their use, too. "Identifier Tracing Protocol (IDTP)", huangng@gmail.com, 2015-05-19, The Identifier Tracing Protocol (IDTP) is an application-level protocol for distributed and collaborative information systems. It is a generic communication protocol which can be used for many tasks with two types of forwarding mechanisms to achieve traceability by using Universal Traceable Identifier (UTID) [I-D-UTID] which contains two types of forwarding messages. This document provides the specification of IDTP, including syntax, data format, and the guidelines for their use, too. "A Simpler Mechanism For Organizing FedFS NSDBs", Chuck Lever, Simo Sorce, 2015-05-20, This document describes a new, simpler mechanism for searching FedFS NSDBs (Name Space Data Bases) for FedFS records. This mechanism replaces the mechanism described in existing FedFS proposed standards. "Recommendations for Local Security Deployments", Hosnieh Rafiee, 2015-05-08, There are currently some mechanisms available to mitigate attacks in local networks -- Secure Neighbor Discovery (SeND), First Hop Security (FHS), SAVI, etc.. The purpose of this document is to compare these mechanisms and offer some recommendations regarding the implementations and deployments of these mechanisms. "6TiSCH On-the-Fly Scheduling", Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura, 2015-07-04, This document describes the environment, problem statement, and goals of On-The-Fly (OTF) scheduling, a Layer-3 mechanism for 6TiSCH networks. The purpose of OTF is to dynamically adapt the aggregate bandwidth, i.e., the number of reserved soft cells between neighbor nodes, based on the specific application constraints to be satisfied. When using OTF, softcell reservation is distributed: through the 6top interface, neighbor nodes negotiate the cell(s) to be (re)allocated/ deleted, with no intervention needed of a centralized entity. This document aims at defining a module which uses the functionalities provided by the 6top sublayer to (i) extract statistics and (ii) determine when to reserve/delete soft cells in the schedule. The exact reservation and deletion algorithm, and the number and type of statistics to be used in the algorithm are out of scope. OTF deals only with the number of softcells to be reserved/deleted; it is up to 6top to select the specific soft cells within the TSCH schedule. "Protocol independent multicast- Next Generation (PIM-NG): Protocol Specifications", saeed sami, 2015-05-24, This document specifies protocol independent multicast- Next generation or simply called PIM-NG. like PIM-SM, PIM-NG uses the underlying unicast routing information, but unlike PIM-SM it doesn't necessarily need to build unidirectional shared trees rooted at a Rendezvous Point (RP) per group, due to the fact that the processes through which a source registers with the Rendezvous Point and a host finds the source of the multicast destination groups it needs are done in a whole new way. So at some points PIM-NG works faster than its predecessor. Also the new Domain concept, unique to PIM-NG, along the RPF check method used in PIM-NG specifications provides many features along a robust and flexible control and administration over multicast networks. "Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths", Udayasree Palle, Dhruv Dhody, Yosuke Tanaka, Zafar Ali, Vishnu Pavan Beeram, 2015-06-29, The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE LSPs. This document provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in supporting point-to-multipoint (P2MP) TE LSPs. "Signaling Entropy Label Capability Using IS-IS", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2015-04-20, Multi Protocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated that it can process ELs for that tunnel. This draft defines a mechanism to signal that capability using IS-IS. This mechanism is useful when the label advertisement is also done via IS-IS. "IP Delivery Delay Detection Protocol", Brian Weis, Umesh Mangla, Nilesh Maheshwari, Thomas Karl, 2015-06-01, This memo describes a one-way measurement of IP packet end to end delay. Delay detection is enabled by a sender of an IP Internet Protocol datagram placing a timestamp in the packet declaring the time at which it was sent. The receiver of the datagram can then judge how recently it was sent and choose a policy action, which could include discarding packets deemed to be 'too old' (having a timestamp too far into the past) or 'too new' (having a timestamp that is too far into the future). "Generic Fault-avoidance Routing Protocol for Data Center Networks", Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish, 2015-04-29, This draft proposes a generic routing method and protocol for a regular data center network, named as the fault-avoidance routing (FAR) protocol. FAR protocol provides a generic routing method for all types of network architectures that are proposed for large-scale cloud-based data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a simplistic manner. Fat-tree is taken as an example architecture to illustrate how FAR protocol can be applied in real operational scenarios. "Asymmetric Extended Route Optimization (AERO)", Fred Templin, 2015-06-17, This document specifies the operation of IP over tunnel virtual links using Asymmetric Extended Route Optimization (AERO). Nodes attached to AERO links can exchange packets via trusted intermediate routers that provide forwarding services to reach off-link destinations and redirection services for route optimization. AERO provides an IPv6 link-local address format known as the AERO address that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 ND to IP forwarding. Admission control, provisioning and mobility are supported by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), and route optimization is naturally supported through dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND messaging are used in the control plane, both IPv4 and IPv6 are supported in the data plane. AERO is a widely-applicable tunneling solution using standard control messaging exchanges as described in this document. "Yang Data Model for Service Function Chaining", Reinaldo Penno, Paul Quinn, Danny Zhou, Johnson Li, 2015-03-02, This document defines a YANG data model that can be used to configure and manage Service Function Chains. "An IP option for describing the traffic flow", Robert Chodorek, 2015-06-09, Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. The proposed IP option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes. "SAML Profile for the Metadata Query Protocol", Ian Young, 2015-04-28, This document profiles the Metadata Query Protocol [I-D.young-md-query] for use with SAML metadata [SAML2Meta]. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.6. "Email Exchange of Secondary School Transcripts", James Davin, 2015-06-25, A common format simplifies exchange of secondary school academic transcripts via electronic mail. Extant standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice. "CBOR data definition language: a notational convention to express CBOR data structures.", Christoph Vigano, Henk Birkholz, 2015-07-06, 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. "Framework for Abstraction and Control of Transport Networks", Daniele Ceccarelli, Young Lee, 2015-03-09, This draft provides a framework for abstraction and control of transport networks. "Deterministic Forwarding PHB", Shitanshu Shah, Pascal Thubert, 2015-03-01, This document defines a Differentiated Services Per-Hop-Behavior (PHB) Group called Deterministic Forwarding (DF). The document describes the purpose and semantics of this PHB. It also describes creation and forwarding treatment of the service class. The document also describes how the code-point can be mapped into one of the aggregated Diffserv service classes [RFC5127]. "Additional Reserved Top Level Domains", Lyman Chapin, Mark McFadden, 2015-03-02, The Internet Domain Name System (DNS) defines a tree of names starting with root, ".", immediately below which are top level domain (TLD) names such as ".com" and ".us". In June 1999 [RFC2606] reserved a small number of TLD names for use in documentation examples, private testing, experiments, and other circumstances in which it is desirable to avoid conflict with current or future actual TLD names in the DNS. There has been significant evolution of Internet engineering and operation practices since [RFC2606] was published. In February 2013 [RFC6761] defined criteria and procedures for reserving a domain name for special use, and established an IANA registry for such names. This document reserves three domain name labels for special use in accordance with the criteria and procedures of [RFC6761]: home, corp, and mail. It is important to note that TLD names may be reserved, in other contexts, for policy, political, or other reasons that are distinct from the IETF's concern with Internet engineering and operations. This document reserves TLD names only for operational and engineering reasons. "The GeoJSON Format", H. Butler, M. Daly, A. Doyle, Sean Gillies, Stefan Drees, 2015-01-28, GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. This document recommends a single coordinate reference system based on WGS 84. Other coordinate reference systems are not recommended. "Opportunistic Security in MPLS Networks", Adrian Farrel, Stephen Farrell, 2015-06-17, This document describes a way to apply opportunistic security between adjacent nodes on an MPLS Label Switched Path (LSP) or between end points of an LSP. It explains how keys may be agreed to enable encryption, and how key identifiers are exchanged in encrypted MPLS packets. Finally, this document describes the applicability of this approach to opportunistic security in MPLS networks with an indication of the level of improved security as well as the continued vulnerabilities. This document does not describe security for MPLS control plane protocols. "Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN)", Dhruv Dhody, Xian Zhang, Oscar Gonzalez de Dios, Daniele Ceccarelli, Bin-Yeong Yoon, 2015-04-16, This document describes the Abstraction and Control of Transport Networks (ACTN) use cases related to Packet and Optical Integration (POI), that may be potentially deployed in various transport networks and apply to different applications. "Barreto-Naehrig Curves", Kohei Kasamatsu, Satoru Kanno, Tetsutaro Kobayashi, Yuto Kawahara, 2015-07-06, Elliptic curves with pairings are useful tools for constructing cryptographic primitives. In this memo, we specify domain parameters of Barreto-Naehrig curves (BN-curves) [8]. The BN-curve is an elliptic curve suitable for pairings and allows us to achieve high security and efficiency of cryptographic schemes. This memo specifies domain parameters of four 254-bit BN-curves [1] [2] [5] which allow us to obtain efficient implementations. "Experimental Option for TCP Host Identification", Brandon Williams, Mohamed Boucadair, Dan Wing, 2015-04-10, Recent IETF proposals have identified benefits to more distinctly identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy. Analysis indicates that the use of a TCP option for this purpose can be successfully applied to a broad range of use cases. This document describes a common experimental TCP option format for host identification. "Captive-Portal Identification in DHCP / RA", Warren Kumari, Ólafur Guðmundsson, Paul Ebersman, Steve Sheng, 2015-06-18, In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a RA extension) to inform clients that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. [ Ed note (remove): This document is being developed in github: https://github.com/wkumari/draft-wkumari-dhc-capport . ] "Federated Filesystem Security Addendum", Chuck Lever, 2015-05-20, This document addresses critical security-related items that are missing from existing FedFS proposed standards. "NVO3 Operations, Administration, and Maintenance Requirements", Hao Chen, Peter Ashwood-Smith, Liang Xia, Ranga Iyengar, Tina Tsou, Ali Sajassi, Mohamed Boucadair, Christian Jacquenet, Masahiro Daikoku, Anoop Ghanwani, Ram (Ramki) Krishnan, 2015-07-08, This document provides framework and requirements for Network Virtualization Overlay (NVO3) Operations, Administration, andMaintenance (OAM). "An Authorization Information Format (AIF) for ACE", Carsten Bormann, 2015-07-06, Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated, leading to protocol proposals such as [I-D.gerdes-ace-dcaf-authorize]. One potential work item complementing this protocol work is an Authorization Information Format (AIF). This document provides a strawman for such a format that should enable further discussion of the objectives for its development. "Source-Group Tag eXchange Protocol (SXP)", Michael Smith, Rakesh Kandula, 2015-02-06, This document discusses source-group tag exchange protocol (SXP), a control protocol to propagate IP address to Source Group Tag (SGT) binding information across network devices. "Email archival services supported by may be archive.org", pradeep xplorer, 2015-02-21, This document describes the need for a email archival service supported by an organisation like archive.org to prove later that certain kind of emails were send. "PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model", Udayasree Palle, Dhruv Dhody, Yosuke Tanaka, Zafar Ali, Vishnu Pavan Beeram, 2015-06-29, The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE LSPs. This document provides extensions required for PCEP so as to enable the usage of a stateful PCE initiation capability in recommending point-to-multipoint (P2MP) TE LSP instantiation. "The 'XML2RFC' version 3 Vocabulary", Paul Hoffman, 2015-07-06, This document defines the "XML2RFC" version 3 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 2629 and its expected followup, draft-iab-xml2rfc. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the rfc-interest mailing list (rfc-interest@rfc-editor.org), which has its home page at . "Definitions of Managed Objects for the LDP Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula, Uwe Joorde, Arvind Venkateswaran, 2015-04-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing multicast LDP point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB module defined in this document is extension of LDP MIB defined in RFC3815 which supports only for LDP point-to-point LSPs. "SVG Drawings for RFCs: SVG 1.2 RFC", Nevil Brownlee, 2015-03-30, 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. "PCEP Extensions for Receiving SRLG Information", Dhruv Dhody, Fatai Zhang, Xian Zhang, Victor Lopezalvarez, Oscar Gonzalez de Dios, 2015-02-06, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document provides extensions for the Path Computation Element Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information during path computation via encoding this information in the path computation reply message. "BGP Auto Discovery", Robert Raszuk, Warren Kumari, Jon Mitchell, Keyur Patel, John Scudder, 2015-04-20, This document describes a method for automating portions of a router's BGP configuration via discovery of BGP peers with which to establish further sessions from an initial "bootstrap" router. This method can apply for establishment of either Internal or External BGP peering sessions. "mDNS X-link review", Douglas Otis, 2015-05-19, Multicast DNS will not normally extend beyond the MAC Bridge. This limitation is problematic when desired services are beyond the reach of multicast mDNS. This document explores security considerations when overcoming this limitation. "Support for File System Extended Attributes in NFSv4", Manoj Naik, Marc Eshel, 2015-07-05, This document proposes extensions to existing NFSv4 operations to allow file extended attributes (here forth also referred to as xattrs) to be manipulated in the protocol. An xattr is a file system feature that allows opaque metadata, not interpreted by the file system, to be associated with files and directories and are supported by many modern file systems. New file attributes are proposed to allow clients to query the server for xattr support, and new operations to get and set xattrs on file system objects. "Connecting MPLS-SPRING Islands over IP Networks", Xiaohu Xu, Robert Raszuk, Uma Chunduri, Luis Contreras, 2015-03-02, MPLS-SPRING is an MPLS-based source routing paradigm in which a sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels to the packet. To facilitate the incremental deployment of this new technology, this document describes a mechanism which allows the outermost LSP be replaced by an IP-based tunnel. "Cooperating Layered Architecture for SDN", Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna, 2015-07-06, Software Defined Networking proposes the separation of the control plane from the data plane in the network nodes and its logical centralization on a control entity. Most of the network intelligence is moved to this functional entity. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities. This document describes a proposal named Cooperating Layered Architecture for SDN. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path. "IGP extension for PCEP security capability support in the PCE discovery", Diego Lopez, Qin Wu, Dhruv Dhody, Daniel King, 2015-03-06, When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCEP security (e.g., Transport Layer Security(TLS)) support capability. This document proposes new capability flag bit for PCE-CAP-FLAGS sub- TLV that can be announced as attribute in the IGP advertisement to distribute PCEP security support information. "A Configuration File Format for Extensible Authentication Protocol (EAP) Deployments", Stefan Winter, 2015-07-06, This document specifies a YANG module and derived XML and JSON file formats for transfering configuration information of deployments of the Extensible Authentication Protocol (EAP). Such configuration files are meant to be discovered, consumed and used by EAP supplicant software to achieve secure and automatic EAP configuration on the consuming device. "PCEP Extensions for traffic steering support in Service Function Chaining", Wenson Wu, Dhruv Dhody, Mohamed Boucadair, Christian Jacquenet, Jeff Tantsura, 2015-06-30, This document provides an overview of the usage of Path Computation Element (PCE) with Service Function Chaining (SFC); which is described as the definition and instantiation of an ordered set of such service functions (such as firewalls, load balancers), and the subsequent "steering" of traffic flows through those service functions. This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate Service Function Paths (SFP). "Cloud of Secure Elements(CoSE)", Pascal Urien, 2015-02-07, This document describes an architecture named "Cloud of Secure Elements (CoSE)" whose goal is to strengthen the Internet trust. A Secure element (SE) provides secure services thanks to various means such as tamper resistant technologies or software virtualization techniques. Secure elements are hosted in dedicated servers (i.e. Trusted Secure Elements Servers, TSES); they provide secure storage facilities or compute cryptographic procedures. Secure elements resources are identified by dedicated URIs and should also support HTTP interface. Users are equipped with "Access Credential" and thanks to the Secure Transport Protocol (STP-TSES) remotely access to Secure Element embedded resources. The RACS (Remote APDU Call Secure) and its associated framework protocol is an early proof of concept of the CoSE concept. "Simplified Local internet nUmber Resource Management with the RPKI", David Mandelberg, 2015-05-13, The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. In the future, ISPs also will be able to use the RPKI to validate the path of a BGP route. Some ISPs locally use BGP with private address space or private AS numbers (see RFC6890). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid based on the global RPKI (see RFC6491). The mechanisms described below provide ISPs with a way to make local assertions about private (reserved) INRs while using the RPKI's assertions about all other INRs. "IPv6 mapping to non-IP protocols", Gianluca Rizzo, Antonio Jara, Alex Olivieri, Yann Bocchi, Maria Palattella, Latif Ladid, Sebastien Ziegler, Cedric Crettaz, 2015-03-28, IPv6 is an important enabler of the Internet of Things, since it provides an addressing space large enough to encompass a vast and ubiquitous set of sensors and devices, allowing them to interconnect and interact seamlessly. To date, an important fraction of those devices is based on networking technologies other than IP. An important problem to solve in order to include them into an IPv6-based Internet of Things, is to define a mechanism for assigning an IPv6 address to each of them, in a way which avoids conflicts and protocol aliasing. The only existing proposal for such a mapping leaves many problems unsolved and it is nowadays inadequate to cope with the new scenarios which the Internet of Things presents. This document defines a mechanism, 6TONon-IP, for assigning automatically an IPv6 address to devices which do not support IPv6 or IPv4, in a way which minimizes the chances of address conflicts, and of frequent configuration changes due to instability of connection among devices. Such a mapping mechanism enables stateless autoconfiguration for legacy technology devices, allowing them to interconnect through the Internet and to fully integrate into a world wide scale, IPv6-based IoT. "NVO3 Fault Management", Tissa Senevirathne, Samer Salam, Deepak Kumar, Norman Finn, Donald Eastlake, Sam Aldrin, 2015-06-26, This document specifies Fault Management solution for network virtualization overlay networks. Methods in this document follow the IEEE 802.1 CFM framework and reuse OAM tools where possible. Additional messages and TLVs are defined for IETF overlay OAM specific applications or where extensions beyond IEEE 802.1 CFM are required. "Impact of Virtualization and SDN on Emerging Network Coding", Bhumip Khasnabish, Senthil Sivakumar, Evangelos Haleplidis, Cedric Adjih, 2015-03-09, Network Coding is a technique used to code packets and be able to recover coded packets from loses. It requires at least two participating nodes in the path of the packet, one to encode and another to decode. This document discusses the impact of virtualization and Software-Defined Networking (SDN) on the emerging network coding. This document also discusses the integration of network coding in various layers of the network stack and the APIs required from the network coding entity to program it from a controller. "Differentiated prIorities and Status Code-points Using Stun Signalling (DISCUSS)", Paal-Erik Martinsen, Herb Wildfeuer, 2015-02-12, This draft describes a mechanism for information exchange between an application and the network. The information provided from the application to the network MAY be used by a network element in the path to modify its behavior to improve application quality of experience (QoE). Likewise, the information provided by the network to the application MAY be used by the application to modify its behavior to optimize for QoE. The information provided from the application to the network can also be useful for middleboxes that are responsible for security at edges of network (e.g. firewalls) or other middleboxes in determining how to treat the packets delivered from this application. "An Information model for service topology", Susan Hares, Wenson Wu, Zitao Wang, Jianjie You, 2015-01-29, As stated in [I.D-ietf-sfc-problem-statement], the service overlay is independent of the network topology and allows operators to use whatever overlay or underlay they prefer and to locate service nodes in the network as needed. This document extends the general topology model concept defined in [I.D-medved-i2rs-topology-im] and focuses on defining information model for service topology. "Generic Overlay OAM and Datapath Failure Detection", Pradeep Jain, Kanwar Singh, Diego Rio, Wim Henderickx, Vinay Bannai, Ravi Shekhar, Anil Lohiya, 2015-03-07, This proposal describes a mechanism that can be used to detect Data Path Failures of various overlay technologies as VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data Plane for given Overlay Segment. This document defines the following for each of the above Overlay Technologies: o Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment. o The mechanism to trace the Underlay that is exercised by any Overlay Segment. o Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point. Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are generic enough to accommodate OAM for any other Overlay Technology. "service function chain Use Cases in Broadband", Chongfeng Xie, Qiong, Wei Meng, Cui Wang, Bhumip Khasnabish, 2015-03-09, This document discusses about service function chain use cases in different scenarios of broadband network. The document provides analysis of different solutions and also describes the feasible deployment scenarios corresponding to each solution. "Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)", Daniel Migault, Valery Smyslov, 2015-03-04, This document considers a VPN End User establishing an IPsec SA with a Security Gateway using the Internet Key Exchange Protocol Version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address. With the current IKEv2 protocol, the outer IP addresses of the IPsec SA are determined by those used by IKE SA. As a result using multiple interfaces requires to set up an IKE SA on each interface, or on each path if both the VPN Client and the Security Gateway have multiple interfaces. Setting each IKE SA involves authentications which might require multiple round trips as well as activity from the VPN End User and thus would delay the VPN establishment. In addition multiple authentications unnecessarily increase the load on the VPN client and the authentication infrastructure. This document presents the solution that allows to clone IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster mode using MOBIKE protocol. "Global Synchronization Protection for Packet Queues", Wolfram Lautenschlaeger, 2015-03-09, The congestion avoidance processes of several transmission capacity sharing TCP flows tend to be synchronized among each other, so that the rate variations of the individual flows do not compensate. In contrary, they accumulate into large variations of the whole aggregate. The effect is known as global synchronization. Large queuing buffer demand and large latency and jitter are the consequences. Global Synchronization Protection (GSP) is an extension of regular tail drop packet queuing schemes that prevents global synchronization. For large traffic aggregates the de-correlation between the individual flow variations reduces buffer demand and packet sojourn time by an order of magnitude and more. Even though quite simple, the solution has a theoretical background and is not heuristic. It has been tested with a Linux kernel implementation and shows equivalent performance as other relevant AQM schemes. "DNSSEC Validators Requirements", Daniel Migault, 2015-02-17, DNSSEC provides data integrity and authentication for DNSSEC validators. However, without valid trust anchor(s) and an acceptable value for the current time, DNSSEC validation cannot be performed. This document lists the requirements to be addressed so resolvers can have DNSSEC validation can be always-on. "Experience from MAP-T Testing", Edwin Cordeiro, Rodrigo Carnier, Antonio Moreiras, 2015-07-03, This document describes the testing result of a network using MAP-T double translation solution, by providing an overview of user applications' behavior with a shared IPv4 address. The MAP-T software is from CERNET Center and the test environment is on NIC.br network with real and virtualized machines. "Use Cases and Requirements of Dynamic Service Control based on Performance Monitoring in ACTN Architecture", Yunbin Xu, Guoying Zhang, Weiqiang Cheng, zhenghaomian@huawei.com, 2015-04-26, This document introduces the dynamic creation, modification and optimization of services based on the performance monitoring in the Abstraction and Control of Transport Networks (ACTN) architecture. "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", Eric Osterweil, Glen Wiley, Tomofumi Okubo, Ramana Lavu, Aziz Mohaisen, 2015-07-06, This document defines a new Domain Name System (DNS) resource record type called the IPSECA RR that is used to associate an X.509 certificate or a public key to an Internet Protocol Security (IPsec) gateway in a similar manner TLSA RR is used in the DNS-based Authentication of Named Entities (DANE) protocol does that for Transport Layer Security (TLS) in order to make the credential discovery easier through DNS and to allow credential discovery to be performed in a secure manner leveraging DNS Security Extensions (DNSSEC). Among the issues addressed in this draft is the danger of IP address spoofing that can be a liability to IPsec endpoints. It is important to note that the "right destination" in this document is strictly defined by the response of the DNS and does not attest to the identity of the organization or the ownership of the IP address space. The identity of the organization shall be attested in an X.509 certificate issued by a certification authority if desired and the ownership of the IP address space shall be attested by other mechanisms such as Towards A Secure Routing System (TASRS) architecture or Resource Public Key Infrastructure (RPKI). "Extended End Point Properties for Application-Layer Traffic Optimization", Deng Lingli, Haibin Song, Sebastian Kiesel, Yang Yang, Wenson Wu, 2015-06-10, The purpose of the Application-Layer Traffic Optimization (ALTO) protocol is to provide better-than-random peer selection for P2P networks. The base ALTO protocol focuses, only on providing network topological location information (i.e., network maps and cost maps). However, the peer selection method of an endpoint may also use other properties, such as geographic location. This document defines a framework and an extended set of End Point properties (EP properties) to extend the base ALTO protocol. "Extensions to Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", Xian Zhang, zhenghaomian@huawei.com, Oscar Gonzalez de Dios, Victor Lopez, 2015-07-06, Resource sharing in a network means two or more Label Switched Paths (LSPs) use common piece(s) of resource along their paths. This can help save network resource and useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is a centralized entity, responsible for path computation. Given this feature and its access to the network resource information and possibly active LSPs information, it can be used to support resource-sharing-based path computation with better efficiency. This document extends the Path Computation Element Protocol (PCEP) in order to support resource sharing-based path computation. "Service Function Chaining (SFC) Control Plane Components & Requirements", Hongyu Li, Qin Wu, Mohamed Boucadair, Christian Jacquenet, Walter Haeffner, Seungik Lee, Ron Parker, Linda Dunbar, Andrew Malis, Joel Halpern, Tirumaleswar Reddy, Prashanth Patil, 2015-06-08, This document describes requirements for conveying information between Service Function Chaining (SFC) control elements (including management components) and SFC functional elements. Also, this document identifies a set of control interfaces to interact with SFC- aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. "Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE certificates", Brigitte Lonc, 2015-06-12, This document specifies the use of two new certificate types to authenticate TLS entities. The first type enables the use of a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) [IEEE-ITS] and the second by the European Telecommunications Standards Institute (ETSI) [ETSI-ITS]. "DHCP Options for Configuring Tenant Identifier and Multicast Addresses in Overlay Networks", Behcet Sarikaya, Frank Xia, Fan Shi, 2015-05-15, This document defines DHCPv4 and DHCPv6 options for assigning VXLAN Network Identifier and multicast addresses for overlay networks such as the Virtual eXtensible Local Area Network (VXLAN). New DHCP options are defined which allow a Network Virtualization Edge to request any source multicast address and tenant identifier for the newly created virtual machine. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 2015-03-04, Although the SIP History-Info header field is the solution adopted in IETF, the non-standard Diversion header field is nevertheless already implemented and used for conveying call diversion related information in the Session Initiation Protocol (SIP) signaling. On one hand, the non-standard Diversion header field is described, as Historic, in [RFC5806]. On the other hand, the History-Info header field is described in [RFC7044] that obsoletes the original[RFC4244] describing the History-Info header field. [RFC7044] defines the SIP header field, History-Info, for capturing the history information in requests and new SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. [RFC7044] also defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. This work is intended to enable the migration from non-standard implementations and deployments toward IETF specification-based implementations and deployments. This document obsoletes [RFC6044]that describes the interworking between the Diversion header field [RFC5806] and the obsoleted History-Info header field as defined on [RFC4244]. "Distributed mobility management deployment scenario and architecture", Vic Liu, Dapeng Liu, Anthony Chan, Deng Lingli, 2015-07-06, This document discusses the deployment scenario of distributed mobility management. The purpose of this document is to trigger the discussion in the group to understnad the DMM deployment scenario and consideration from the operator's perspective. "Overview for MSRP Recording based on SIPREC", Michael Yan, Paul Kyzivat, 2015-02-27, SIPREC is capable of recording interactive text media that is transmitted via RTP. However that format is not commonly used for message or chat scenarios. There is also a need for recording text media carried via MSRP. One case of note is exchange of text between hearing-impaired users and emergence service bureaus. Also, recording support is needed for MSRP used in chat conferences and multimedia conferences. This document describes how to achieve MSRP channel recording within the mechanism of SIP Recording (SIPREC). "Virtualisation of Mobile Core Network Use Case", Daniel King, Marco Liebsch, Peter Willis, Jeong-dong Ryoo, 2015-01-31, Accessing the Internet via mobile data services using smartphones, tablets, and mobile data USB dongles has increased rapidly, as high-speed packet data networks provide the bandwidth required for today's Internet applications. Mobile operators will continue to evolve their core networks to the Long Term Evolution (LTE) Evolved Packet Core (EPC) to meet the mobility, latency and bandwidth requirements for mobile data users. Network Functions Virtualization (NFV) looks to reduce mobile core network complexity and related operational issues by leveraging standard IT virtualization technologies and consolidate different types of network equipment onto commodity hardware. This use case document provides resiliency requirements for virtualization of the LTE mobile core network, known as virtualized EPC (vEPC). "Implementing RPKI-based origin validation one country at a time. The Ecuadorian case study.", Fabian Mejia, Roque Gagliano, Alvaro Retana, Carlos Martinez, Gerardo Rada, 2015-03-03, One possible deployment strategy for BGP origin validation based on the Resource Public Key Infrastructure (RPKI) is the construction of islands of trust. This document describes the authors' experience deploying and maintaining a BGP origin validation island of trust in Ecuador. "On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks", Yunjung Yi, Sung-Ju Lee, William Su, Mario Gerla, Axel Verdiere, 2015-02-24, The On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing protocol designed for ad hoc networks with mobile hosts. ODMRP is a mesh-based, rather than a conventional tree-based, multicast scheme and uses a forwarding group concept (only a subset of nodes forwards the multicast packets via scoped flooding). It applies on-demand procedures to dynamically build routes and maintain multicast group membership, without relying on pre-existing unicast routing protocols. ODMRP is well suited for ad hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and rapidly, and power is constrained. "LISP Reliable Transport", Christian Cassar, Isidor Kouvelas, Darrel Lewis, 2015-03-27, The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. "Concise Binary Object Representation (CBOR) Tags for Typed Arrays", Johnathan Roatch, Carsten Bormann, 2015-06-17, The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data. It is intended as the reference document for the IANA registration of the CBOR tags defined. "The Use of Non-ASCII Characters in RFCs", Heather Flanagan, 2015-01-30, In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and guidance regarding the use of non-ASCII characters in RFCs. This document updates RFC 7322. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Quintin Zhao, Katherine Zhao, Zhenbin Li, Dhruv Dhody, Udayasree Palle, Telus Communications, 2015-03-02, In certain networks deployment scenarios, service providers would like to keep all the existing MPLS functionalities in both MPLS and GMPLS while removing the complexity of existing signaling protocols such as LDP and RSVP-TE. In [I-D.zhao-pce-central-controller-user-cases], we propose to use the PCE [RFC5440] as a central controller (PCECC) so that LSP can be calculated/ signaled/initiated and label forwarding entries are downloaded through a centralized PCE server to each network devices along the LSP path while leveraging the existing PCE technologies as much as possible. This draft specify the procedures and PCEP protocol extensions for using the PCE as the central controller and user cases where LSPs are calculated/setup/initiated and label forwarding entries are downloaded through extending the existing PCE architectures and PCEP. This document also discuss the role of PCECC in Segment Routing (SR). "Requirements for IPv6 Enterprise Firewalls", Fernando Gont, Marco Ermini, Shucheng LIU, 2015-03-09, While there has been some work in the area of firewalls, concrete requirements for IPv6 firewalls have never been specified in the RFC series. The more limited experience with the IPv6 protocols and the more reduced number of firewalls that support IPv6 has made it rather difficult to infer what are reasonable features to expect in an IPv6 firewall. This has typically been a problem for network operators, who typically have to produce a "Request for Proposal" from scratch that describes such features. This document specifies a set of requirements for IPv6 firewalls, in order to establish some common- ground in terms of what features can be expected in them. "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2015-06-08, 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. "MOBIKEv2: MOBIKE extension for Transport mode", Daniel Migault, Daniel Palomares, 2015-02-16, MOBIKE, the IKEv2 Mobility and Multihoming Protocol is defined only for CHILD_SA using the tunnel mode. This document describes MOBIKEv2 that extends MOBIKE for CHILD_SA using also transport mode. "I2RS Security Considerations", Susan Hares, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Qin Wu, Ahmed Abro, Salman Asadullah, Joel Halpern, Eric Yu, 2015-02-06, This presents an expansion of the security architecture found in the i2rs architecture. "An IETF with Much Diversity and Professional Conduct", dcrocker, Narelle Clark, 2015-06-14, The process of producing today's Internet technologies, through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. For its early years, participation in the IETF and its antecedent was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation, in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF. "IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils, Brian Field, Ida Leung, 2015-05-05, Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending a SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. "Email provider should provide email owner an audit log", pradeep xplorer, 2015-04-17, This document describes the need for an email service provider to provie a feature to the email owner to log who and where has logged into his email by an email itself if possible. "Solution for Site Multihoming in a Real IP Environment", Shyam Bandyopadhyay, 2015-01-05, This document provides a solution for Site Multihoming of stub networks in a real IP environment. Each user interface in a customer network may have as many global unicast addresses as many service providers it will be connected with. Users can establish multiple connections through different service providers simultaneously. A customer network can maintain private address space to communicate within its users and can share its load while maintaining VPN services. Customer networks can provide IP mobility services as well. "Indicating that out of dialog requests related to an existing dialog must be routed via an intermediary", Andrew Allen, 2015-02-17, This document discusses the problems for out of dialog requests that are related to another dialog, caused by B2BUA intermediaries that modify SIP parameters or terminate dialogs and proposes some possible solutions. "An Architectural Framework of the Internet for the Real IP World", Shyam Bandyopadhyay, 2015-05-01, This document tries to propose an architectural framework of the internet in the real IP world. It shows how to reorganize the provider network with a large address space. It describes how a three-tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and some sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6. "A TCP Authentication Option Extension for Payload Encryption", Joseph Touch, 2015-04-15, This document describes an extension to the TCP Authentication Option (TCP-AO) to encrypt the TCP segment payload in addition to providing TCP-AO's authentication of the payload, TCP header, and IP pseudoheader. This extension augments how the packet contents and headers are processed and which keys are derived, and adds a capability for in-band coordination of unauthenticated Diffie- Hellman key exchange at connection establishment. The extension preserves key rollover coordination and protection of long-lived connections. "ECC Brainpool Curves for DNSSEC", Joern-Marc Schmidt, Johannes Merkle, Manfred Lochter, 2015-06-16, This document specifies the use of ECDSA with ECC Brainpool curves in DNS Security (DNSSEC). It comprises curves of two different sizes. "Compression of IPsec AH and ESP Headers for Constrained Environments", Shahid Raza, Simon Duquennoy, Goran Selander, 2015-06-22, This document describes the header compression mechanisms for IPsec [RFC4301] based on the encoding scheme standardized in [RFC6282]. The IPsec Authentication Header (AH) and Encapsulated Security Payload (ESP) headers are compressed using Next Header Compression (NHC) defined in [RFC6282]. This document does not invalidate any encoding schemes proposed in 6LoWPAN [RFC6282] but rather complements it with compressed IPsec AH and ESP headers using the free bits in the IPv6 Extension Header encoding. "Ethernet LDP( Label Distribution with out IP and routing protocols)", sudhin jacob, 2015-03-25, MPLS is the heart and soul of the service provider network. MPLS can carry anydata payload which gives the flexibility to the service provider to provision new service with any expense.The benefit of this technology is core router need not understand the full customer route. If the service a layer 2 then thereis no need of vrf, for customer the service provider cloud is like a virtual switch.The protocol used for label distribution is LDP, BGP,RSVP. The most popular protocol for outer label distribution is LDP. LDP has the benefit of adding more TLV to its payload. In this the possibility of using ldp for generating labels for mac address rather for ip address which gives the benefit to service provider not to run complex routing protocol on core, this does not require ip address. This gives service provider the flexibility to deploy any services, there is no need for changes in network layer when the customer goes for ipv4 to ipv6. This can reduce the CAPEX and OPEX of the customer and reduces the hardware cost too. "PCE support for Maximizing Diversity", Dhruv Dhody, Qin Wu, 2015-06-08, The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions. In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a set of services that are required to be diverse (disjointed) from each other. In case when full diversity could not be achieved, it is helpful to maximize diversity as much as possible (or in other words, minimize the common shared resources). This document defines objective function code types for three new objective functions for this purpose to be applied to a set of synchronized path computation requests. "A Common Layer 3 Interface for MANET", Jack Shaio, Caleb Lo, donb@mitre.org, 2015-03-26, This paper presents an approach that allows an algorithm to choose IP routing peers intelligently among the nodes in a MANET but does not involve any modifications to existing IP routing protocols. In addition, our approach works as a pure interface between (any) MANET radio terminal and any IP router, so nodes using our interface interoperate with nodes that do not use this interface or with nodes using different algorithms to select routing peers. This interface was prototyped and this paper includes test results for two different mobility patterns on a mobile network using OLSR for MANET routing and OSPFv2 for IP routing. "Interface to a Packet Switching Element (IPSE)", Rex Fernando, Sami Boutros, Dhananjaya Rao, Nabil Bitar, Luay Jalil, 2015-07-06, This document describes a set of mechanisms for decoupling the control and data plane of a routing or a switching device and describes an open API between the two that satisfies a set of constraints that are desirable for such an interface. "Brotli Compressed Data Format", Jyrki Alakuijala, Zoltan Szabadka, 2015-05-11, This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. "Uniform information with a hybrid naming (hn) scheme", Hong-Ke Zhang, Wei Quan, Jianfeng Guan, Changqiao Xu, Fei Song, 2015-04-05, This document defines a hybrid naming scheme for unifying all kinds of information including resources, services and data. With many proposals of novel network architectures emerging, such as DONA, ICN, NDN, the location-based routing starts to transfer to the content-based ones. Currently, it is incompatible that many different information naming schemes are adopted in different network proposals, respectively, i.e. flat names in DONA, hierarchical names in NDN. The proposed naming scheme adopts a hybrid naming structure, which includes hierarchical component, flat component and attribute component. The hybrid naming (hn) scheme enables to identify different routing information uniformly, and provides many great advantages, such as high aggregation, limited length, suffix holes remission, fuzzy matching support and good compatibility with IPv4/IPv6, DONA and so on. "Security Mechanism Names for Media", Peter Dawes, 2015-04-22, Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in RFC 3329 [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms. "SFC Header Mapping for Legacy SF", Haibin Song, Jianjie You, Lucy Yong, Yuanlong Jiang, Linda Dunbar, Nicolas Bouthors, David Dolson, 2015-07-06, A Service Function Chain (SFC) defines a set of abstract Service Functions (SF) and ordering constraints that must be applied to packets and/or frames selected as a result of classification. One assumption of this document is that legacy service functions can participate in service function chains without having support for the SFC header, or even being aware of it. This document provides a mechanism between an SFC proxy and an SFC-unaware service function (herein termed "legacy SF"), to identify the SFC header associated with a packet that is returned from a legacy SF, without an SFC header being explicitly carried in the wired protocol between SFC proxy and legacy SF. "WebRTC Dependencies", Cullen Jennings, 2015-04-30, This draft will never be published as an RFC and is meant purely to help track the IETF dependencies from the W3C WebRTC documents. "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms", Tony Hansen, 2014-10-27, This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. It also updates RFC 5802 in minor ways. "Encoding claims in the OAuth 2 state parameter using a JWT", J. Bradley, Torsten Lodderstedt, Hans Zandbelt, 2015-05-20, This draft provides a method for a client to encode one or more elements encoding information about the session into the OAuth 2 "state" parameter. "USer Invokable Actions on Desktops to install/copy Websites", pradeep xplorer, 2015-02-21, The document describes the need for a User Invokabke Action in Desktops of Windows , Android and many other Operating systems bundled on mobile computing devices to install or copy a website for offline reading from a filesystem. "Hypertext Transfer Protocol: Improved HTTP Caching", Chris Drechsler, 2015-05-18, This document describes an improved HTTP caching method which can be applied in addition to the standard caching behavior for HTTP. It defines the associated header field that controls this improved caching mechanism and a modified caching operation which is slightly different to standard caching operation for HTTP. "WebRTC Codec Preferences", Kiran Guduru, 2015-01-04, WebRTC specifies to implement a minimum set of required codecs to ensure guaranteed interoperability between WebRTC peers. WebRTC allows browser implementers to support vendor specific codecs apart from mandatory codecs. This document specifies the way for JavaScript applications to give preferences for media codecs in WebRTC context out of the available codecs in browser for creating the offer / answer. "Problem Description for Authorization in Constrained Environments", Ludwig Seitz, Goran Selander, 2015-03-09, We present a problem description for authentication and authorization in constrained-node networks, i.e. networks where some devices have severe constraints on memory, processing, power and communication bandwidth. "Using DNS-based Authentication of Named Entities (DANE) to validate TLS certificates for the Session Traversal Utilities for NAT (STUN) protocol", Marc Petit-Huguenin, oej, Gonzalo Salgueiro, 2015-04-23, This document defines how DNS-based Authentication of Named Entities (DANE) can be used to validate TLS certificates with the Session Traversal Utilities for NAT (STUN) protocol. "X509.v3 certificate extension for authorization of device ownership", Michael Richardson, 2015-03-26, This document details an X.509 extension to provide authorization and indication of ownership of a constrained device containing 802.1AR IDevID. "Segment Routing Centralized Egress Peer Engineering", Clarence Filsfils, Stefano Previdi, Keyur Patel, Ebben Aries, shaw@fb.com, Daniel Ginsburg, Dmitry Afanasiev, 2015-07-06, 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 illustrates the application of Segment Routing to solve the Egress Peer Engineering (EPE) requirement. The SR-based EPE solution allows a centralized (SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. This document is on the informational track. "Inter-Cloud Computing Architecture", Mohammad Aazam, 2015-05-17, With the rapid rise in digital content, cloud computing has become the focus of academia and industry. Cloud computing comes with sophisticated technologies for data storage, management, and distribution. Ubiquitous access facility and pay-as-you-go billing features are additional advantages associated with the cloud computing. However, the massive digital content, more importantly multimedia, has to be managed in a more effective way. Heterogeneous cloud customers, accessing different customized services, with more advanced access networks and devices available today, makes it tough at times for solitary clouds to fulfill the needs. In such cases, different clouds have to interoperate and federate their resources. This scenario is called inter-cloud computing of cloud federation. Since the concept of inter-cloud computing is still very new, it lacks standard architecture. This document focuses on presenting architectural fundamentals and key concerns associated with inter-cloud computing. "The Session Initiation Protocol (SIP) OAuth", Rifaat Shekh-Yusef, Victor Pascual, 2015-04-13, This document defines an authorization framework for SIP that is based on the OAuth 2.0 framework, and adds a simple identity layer on top of that, based on the OpenID Connect Core 1.0, to enable Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User. "RTP Payload Format for MELPe Codec", Victor Demjanenko, David Satterlee, 2015-06-03, This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder algorithm developed by Atlanta Signal Processing (ASPI), Texas Instruments (TI), SignalCom (now Microsoft) and Thales Communications with noise preprocessor contributions from AT&T under contract with NSA/DOD as international NATO Standard STANAG 4591. All three different speech encoding rates and sample frames sizes are included. Comfort noise procedures and packet loss concealment are detailed. Also, within the document there are included necessary details for the use of MELP with SDP. "Third-Party Authorization Label", Douglas Otis, 2015-04-21, This experimental specification proposes a Third-Party Authorization Label (TPA-Label) as a DNS-based method that allows Trusted Domains an efficient means to authorize acceptable Third-Party Domains. This method permits autonomous unilateral authorizations and uses scalable individual DNS transactions. A TPA-Label Resource Record transaction asserts an alignment exception to convey informally Federated Domains. It affords recipients a practical and safe means to extend Domain Alignment. Exceptions are managed by either the Trusted Domain, or their agent, seeking to avoid disruption of informal services enjoyed by their users. Third-Party Authorization of a Federated Domain eliminates a need to share private credentials. "Use-cases for Collaborative LMAP", Deng Lingli, Rachel Huang, Shihui Duan, 2015-06-03, This document discusses the motivation and use-cases for collaborative LMAP practices, where multiple autonomous measurement systems collaborate together in performing large scale performance measurements to help with QoE enhancement by ICPs, network performance monitory to guide ISP/Regulator coordination between autonomous network domains and/or regulatory policies and cross- boundary troubleshooting for complaints from end consumers. "Advertising Service Functions Using IS-IS", Xiaohu Xu, Nan Wu, Himanshu Shah, Luis Contreras, 2015-06-03, Source Packet Routing in Networking (SPRING) WG specifies a special MPLS-based source routing mechanism, called MPLS-SPRING. Such source routing mechanism can be leveraged to realize the service path layer functionality of service function chaining (i.e, steering traffic through a particular service function path) by encoding the service function path information as an explicit path information in the form of an MPLS label stack. This document describes how to advertise service functions and their corresponding attributes (e.g.,segment ID) using IS-IS. "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Goran Selander, Carsten Bormann, 2015-04-29, 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 elements of an architecture / a problem statement, for authentication and authorization in these networks. "SHA-2 Algorithm for the TCP Authentication Option (TCP-AO)", Sujeet Ammunje, Brian Weis, 2015-01-26, The TCP Authentication Option (TCP-AO) relies on security algorithms to provide connection authentication between the two end-points. This document specifies how to use SHA-256 algorithm and attributes with TCP-AO. "Enhancing Virtual Network Encapsulation with IPv6", Mark Smith, 2015-06-15, A variety of network virtualization over layer 3 methods are currently being developed and deployed. These methods treat IPv4 and IPv6 as equivalent underlay network technologies. This memo suggests how IPv6's additional capabilities may be used to enhance Virtual Network encapsulation over an IPv6 Underlay Network. "Delegating DKIM Signing Authority", Murray Kucherawy, dcrocker, 2015-04-10, DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. "A List-safe Canonicalization for DomainKeys Identified Mail (DKIM)", Murray Kucherawy, 2015-04-05, DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a structured message such as conversion between transfer encodings or addition of new message parts. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for generating a canonicalization that can allows easy detection of modified content while still being valid for the content it originally signed. It also presents a use profile of DKIM that takes advantage of this capability. "Multicast DNS (mDNS) Threat Model and Security Consideration", Hosnieh Rafiee, 2015-05-30, This document describes threats only specific to extending multicast DNS (mDNS) across layer 3. "Framework for IP Passive Performance Measurements", Lianshu Zheng, Nalini Elkins, Deng Lingli, Michael Ackermann, Greg Mirsky, 2015-02-11, This document describes the framework for passive measurement. In particular, the differences between passive and active measurements are analyzed, general considerations for both metric definition and measurement methodology are discussed, and requirements for various entities performing a given passive measurement task are described according to a reference model. "Mobility with TURN", Dan Wing, Prashanth Patil, Tirumaleswar Reddy, Paal-Erik Martinsen, 2015-05-06, It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. "Mandatory Tags for DKIM Signatures", John Levine, 2015-04-08, The DKIM protocol applies a cryptographic signature to an e-mail message. This specification extends DKIM to allow new signature tags that validators are required to evaluate. The first such tag specifies a second signature that must be present for a signature to be valid. "Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web Browser SSO Profile", Daniela Poehn, Stefan Metzger, Wolfgang Hommel, Michael Grabatin, 2015-06-11, This document specifies the integration of Dynamic Automated Metadata Exchange (DAME) through an intermediate trusted third party into the Security Assertion Markup Language (SAML) 2.0 Web Browser SSO Profile. The user-triggered, on-demand, and fully automated metadata exchange between identity provider (IDP) and service provider (SP) is intended for scenarios in which the a-priori, e.g., federation-based exchange of SAML metadata is neither practical, scalable nor mandatory for non-technical aspects, such as contract-based trust building between IDP and SP. The main benefit of DAME is the removal of waiting times for users and manual setup tasks for IDP and SP administrators before users can access the service. Implementations of DAME can leverage existing metadata repositories, such as REEP, and metadata transfer protocols, such as MD Query. "Requirements for an update to 6LoWPAN ND", Pascal Thubert, Peter Van der Stok, 2015-01-14, Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups suggest that enhancements to the 6LoWPAN ND mechanism are now needed. This document elaborates on those requirements and suggests approaches to serve them. "HTTP/2 Encoded Data", Matthew Kerwin, 2015-06-15, This document introduces a new frame type for transporting gzip- encoded data between peers in the Hypertext Transfer Protocol Version 2 (HTTP/2), and an associated error code for handling invalid encoding. "Requirements for Plain-Text RFCs", Heather Flanagan, 2015-06-21, 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. The high-level requirements that informed this change were defined in RFC6949, "RFC Series Format Requirements and Future Development." Plain text is still an important format for many in the IETF community, and will still 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. "DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro, Victor Pascual, Parthasarathi Ravindran, 2015-03-08, Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often function on the media plane, rather than just on the signaling path. This document describes the behavior B2BUAs should follow when acting on the media plane that use Secure Real-time Transport (SRTP) security context setup with Datagram Transport Layer Security (DTLS) protocol. "Hybrid Access Network Architecture", Nicolai Leymann, Cornelius Heidemann, Margaret Wasserman, Li Xue, Mingui Zhang, 2015-01-13, Residential and Enterprise customers require continuously increasing bandwidth, however it may be difficult for operators to update or rebuild existing fixed access networks, especially when they are deployed in certain areas. This document discusses a general way to address this problem by bundling together multiple heterogeneous access networks according to certain management policies. "Two-way Authentication for IoT", Corinna Schmitt, Burkhard Stiller, Martin Noack, 2015-06-30, In this draft a full two-way authentication security scheme for the Internet of Things (IoT) based on existing Internet standards and protocols is introduced. The solution is twofold providing a two-way authentication for resource-rich hardware (e.g., class 2 devices with ~50 KiB RAM and ~250 KiB ROM [RFC7228]) and for devices with less resources (e.g., class 1 devices with ~10 KiB RAM and ~100 KiB ROM [RFC7228]). By relying on an established standard, existing implementations, engineering techniques, and security infrastructure can be reused, which enables an easy security uptake. The proposed security scheme for resource-rich devices is, therefore, based on RSA, the most widely used public key cryptography algorithm. It is designed to work over standard communication stacks that offer UDP/ IPv6 networking for Low power Wireless Personal Area Networks (6LoWPANs). RSA is a bulky solution at the moment but shows that it is possible using it on constraint devices for security purposes. An optimization is the usage of elliptic curve cryptography (ECC) as assumed for devices with less resources. "PDF for an RFC Series Output Document Format", Tony Hansen, Larry Masinter, Matthew Hardy, 2015-03-25, 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. "GRE Notifications for Hybrid Access", Nicolai Leymann, Cornelius Heidemann, Margaret Wasserman, Li Xue, Mingui Zhang, 2015-01-14, This document specifies a set of GRE (Generic Routing Encapsulation) extensions which enable operators to construct residential networks that are able to access the provider service through more than one hybrid access networks simultaneously in order to satisfy the higher bandwidth requirements. "Binding Self-certifying Names to Real-World Identities with a Web-of- Trust", Jan Seedorf, 2015-03-05, Self-certifying names are one way of binding a given public key to a certain name in Information Centric Networking. However, an additional binding of a self-certifying name to a Real-World identity is needed in most cases, so that a recipient of some information cannot only verify that the publisher was in possession of the correct corressponding private key for the requested name, but that in addition the name itself is the intended one. This draft specifies how such a binding of Real-World identities with self- certifying ICN names can be done, taking existing IETF specifications into account. "PCEP Extensions for service segment used in Segment Routing", Dhruv Dhody, Qin Wu, 2015-03-06, Segment Routing (SR) technology leverages the source routing and tunneling paradigms where a source node can choose a path without relying on hop-by-hop signaling. This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate SR-TE paths that also have a local service segments involved. "Link State protocols SPF trigger and delay algorithm impact on IGP microloops", Stephane Litkowski, 2015-03-06, A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of microloops. The analysis is focused on the SPF triggers and SPF delay algorithm. "PCEP Extensions for Establishing Relationships Between Sets of LSPs", Ina Minei, Edward Crabbe, Siva Sivabalan, Hariharan Ananthakrishnan, Xian Zhang, Yosuke Tanaka, 2015-07-05, This document introduces a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of a stateful PCE as well as a stateless PCE. "SDP codepoints for gateway control", Albrecht Schwarz, Christian Groves, 2015-04-22, SDP is used in many signalling protocols at call control level (such as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC is related to gateway control specific SDP usage. Gateway control protocols do NOT usually define and introduce any new SDP parameters, however, gateway control protocols need specific SDP parameter values in addition to those defined at call or bearer control level. Such SDP codepoints are collected by this RFC with the purpose of registration with IANA. "MPTCP proxy mechanisms", Xinpeng Wei, Chunshan Xiong, Ed, 2015-06-30, Multipath TCP provides the ability to simultaneously use multiple paths between peers for a TCP/IP session, and it could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. This document discusses the mechanism of a new network entity, named MPTCP proxy, which is aimed to assist MPTCP capable peer to use MPTCP session in case of one of the peers not being MPTCP capable or to act as an aggregation point for sublfows. "Applying BGP flowspec rules on a specific interface set", Stephane Litkowski, Adam Simpson, Keyur Patel, Jeffrey Haas, 2015-03-05, 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 does not detail where the flow specification rules need to be applied. This document presents a new interface-set flowspec action that will be used in complement of other actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers on where to apply the flow specification. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. "Need for an httpi intelligent service", pradeep xplorer, 2015-04-17, This document describes the need for an httpi protocol similar to https used for intelligent surfing of information. "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper Networks, Mach Chen, Peng Fan, 2015-06-10, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss. "BGP Extensions for Path Computation Element (PCE) Discovery", Jie Dong, Mach Chen, Dhruv Dhody, Jeff Tantsura, 2015-03-04, In networks where Path Computation Element (PCE) is used for centralized path computation, it is desirable for Path Computation Clients (PCCs) to automatically discover a set of PCEs and select the suitable ones to establish the PCEP session. RFC 5088 and RFC 5089 define the PCE discovery mechanisms based on Interior Gateway Protocols (IGP). This document describes several scenarios in which the IGP based PCE discovery mechanisms cannot be used directly. This document specifies the BGP extensions for PCE discovery in these scenarios. The BGP based PCE discovery mechanism is complementary to the existing IGP based mechanisms. "Usage of the Peer-to-Peer Streaming Protocol (PPSP)", Hong-Ke Zhang, Di Wu, Mi Zhang, Fei Song, 2015-03-09, This document focuses on several crucial operation issues of Peer-to- Peer Streaming Protocol (PPSP) usage, considering two basic modes: Leech mode and Seed mode. Related parameters setting for default PPSP scenario are also given from tracker protocol and peer protocol respectively. In addition, the limitations and gaps of current PPSP system are identified from the standpoint of satisfying PPSP requirements. "Use Cases and Framework of Service-Oriented MPLS Path Programming (MPP)", Zhenbin Li, 2015-03-08, Source Packet Routing in Networking (SPRING) architecture for unicast traffic has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. It can leverage existing MPLS dataplane without any modification. In fact, the label stack capability in MPLS would have been utilized well to implement flexible path programming to satisfy all kinds of requirements of service bearing. But in the distributed environment, the flexible programming capability is difficult to implement and always confined to reachability. As the introducing of central control in the network, the flexible MPLS programming capability becomes possible owing to two factors: 1. It becomes easier to allocate label for more purposes than reachability; 2. It is easy to calculate the MPLS path in a global network view. Moreover, the MPLS path programming capability can be utilized to satisfy more requirements of service bearing in the service layer which is defined as service-oriented MPLS path programming. This document defines the concept of MPLS path programming, then proposes use cases, architecture and protocol extension requirements in the service layer for the architecture of Source Packet Routing in Networking (SPRING). "DHCPv4 over DHCPv6 Source Address Option", Ian Farrer, Qi Sun, Yong Cui, 2015-07-04, 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 is designed to work in conjunction with the IPv4 address allocation process. "Architecture of MPLS/IP Network with Hardened Pipes", JiangTao Hao, Praveen Maheshwari, River Huang, Loa Andersson, Mach Chen, 2015-05-12, This document is intended to become an Informational RFC on the independent stream. The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation, has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line services. This document describes an MPLS/IP network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document the infrastructure has been separated into two strata. One for the 'Hard Pipes', called the 'Hard Pipe Stratum". And one for the normal IP/MPLS traffic - called the 'Normal IP/MPLS stratum'. This document introduces the concept of "Hard Pipes", a Hard Pipe is an MPLS Label Switched Path (LSP) or a Pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon. The Hard Pipe stratum does not use statistical multiplexing, for the LSPs and PWs setup within this stratum the bandwidth are guaranteed end to end. "A YANG model to manage the optical interface parameters of "G.698.2 single channel" in DWDM applications", Gabriele Galimberti, Ruediger Kunze, Hing-Kam Lam, Dharini Hiremagalur, Gert Grammel, Luyuan Fang, Gary Ratterree, 2015-07-06, This memo defines a Yang model that translates the SNMP mib module defined in draft-galikunze-ccamp-g-698-2-snmp-mib for managing single channel optical interface parameters of DWDM applications, using the approach specified in G.698.2. This model is to support the optical parameters specified in ITU-T G.698.2 [ITU.G698.2] and application identifiers specified in ITU-T G.874.1 [ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes, which if used would make the interface a single vendor IaDI and could still be managed. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of the multi-vendor IaDI based on the Black Link approach. "Lightweight and Secure Neighbor Discovery for Low-power and Lossy Networks", Behcet Sarikaya, Frank Xia, Pascal Thubert, 2015-03-09, This document defines a lightweight and secure version of 6LoWPAN Neighbor Discovery for application in low-power and lossy networks. Cryptographically Generated Address and digital signatures are calculated using Elliptic Curve Cryptography, so that the cryptographic operations are suitable for low power devices. An optimal version of this protocol is also specified which supports faster CGA calculation and multi-hop operation. A node computes a Cryptographically Generated Address to be used as a Unique Interface ID, and associate all its Registered Addresses with that Unique Interface ID in place of the EUI-64 that is used in RFC 6775 to uniquely identify the interface of the Registered Address. Once an address is registered with a cryptographic unique ID, only the owner of that ID can modify the state in the 6LR and 6LBR regarding the Registered Address. "BGP Extensions for Service-Oriented MPLS Path Programming (MPP)", Zhenbin Li, 2015-03-08, Service-oriented MPLS programming is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to allocate MPLS segment, download programmed MPLS path and the mapping of the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming. "Use-cases for Passive Measurement in Wireless Networks", Deng Lingli, Lianshu Zheng, Greg Mirsky, 2015-01-10, This document presents use-cases for passive IP performance measurements in wireless networks. "A JSON Encoding for HTTP Header Field Values", Julian Reschke, 2015-03-09, This document establishes a convention for use of JSON-encoded field values in HTTP header fields. "XMPP Protocol Extensions for Use in SACM Information Transport", J. Salowey, Lisa Lorenzin, Clifford Kahn, Scott Pope, Syam Appala, Aaron Woland, Nancy Cam-Winget, 2015-04-29, This document defines a transport protocol for use with the Security Automation and Continuous Monitoring (SACM) Architecture. "Delay-based Metric Extension for the Babel Routing Protocol", Baptiste Jonglez, Juliusz Chroboczek, 2015-05-27, This document defines an extension to the Babel routing protocol that uses symmetric delay in metric computation and therefore makes it possible to prefer lower latency links to higher latency ones. "SFC Use Cases on Recursive Services", Changcheng Huang, Jiafeng Zhu, Peng He, 2015-01-13, Service function chaining (SFC) provides various services that can be tailored to different requirements from diversified user groups, where each user group forms a collective client that requires similar service. SFC is typically deployed as a service overlay with its own service topology on top of existing network topology. This kind of virtualized structure naturally enables recursive service relationship where a client may become a service provider and resell SFC services to its own user groups. Alternatively, a client may also choose to ask its service provider to provide a structured service for its user groups. This document describes some exemplary use cases that show the usage of recursive (e.g. nested) or structured service function chaining relationship. "MIF API extension for combining IEEE 802.21", Hong-Ke Zhang, Boxin Du, Mi Zhang, Fei Song, 2015-05-29, The Application Program Interface (API) of MIF, specified in the MIF API consideration, must rely on lower layer functionalities when handover between homogeneous or heterogeneous networks is necessary. To improve the connectivity experience, the existing MIF API needs to be extended for solving such problem. IEEE is also aimed at the similar issue from different way. A kind of logical entities over the link layer protocol for handling the seamless handover has been defined in IEEE 802.21. This document proposes a mechanism via integrating MIF API and IEEE 802.21 to support application service better. "Timestamp support for BGP paths", Stephane Litkowski, Keyur Patel, Jeffrey Haas, 2015-03-23, BGP is more and more used to transport routing information for critical services. Some BGP updates may be critical to be received as fast as possible : for example, in a layer 3 VPN scenario where a dual-attached site is loosing primary connection, the BGP withdraw message should be propagated as fast as possible to restore the service. The same criticity exists for other address-families like multicast VPNs where "join" messages should also be propagated very fast. Experience of service providers shows that BGP path propagation time may vary depending on network conditions (especially load of BGP speaker on the path) and too long propagation time are affecting customer service. It is important for service providers to keep track of BGP updates propagation time to monitor quality of service for the customers. It is also important to be able to identify BGP Speakers that are slowing down the propagation. This document presents a solution to transport timestamps of a BGP path. The solution is targeted to be used using special identified beacon prefixes that are single-homed. "RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications", Rachel Huang, Alan Clark, 2015-01-07, This draft defines a new video loss concealment block type to augment those defined in [RFC3611] and [RFC7294] for use in a range of RTP video applications. "Back-off SPF algorithm for link state IGP", Bruno Decraene, 2015-03-09, This document defines a standard algorithm to back-off link-state IGP SPF computations. Having one standardized algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence in the area/level when the network reacts to multiple consecutive events. "TFO support for Multipath TCP", Sebastien Barre, Gregory Detal, Olivier Bonaventure, 2015-01-12, TCP Fast Open (TFO) is a TCP extension that allows sending data in the SYN, instead of waiting until the TCP connection is established. This document describes what parts of Multipath TCP must be adapted to support it, and how TFO and MPTCP can operate together. "IPv6 Segment Routing Security Considerations", Eric Vyncke, Stefano Previdi, David Lebrun, 2015-02-27, Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending a SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This document analyzes the security aspects of the Segment Routing Extension Header (SRH) and how it is used by SR capable nodes to deliver a secure service. "Enabling Publish/Subscribe in ICN", Mayutan Arumaithurai, Jiachen Chen, Xiaoming Fu, K. Ramakrishnan, Jan Seedorf, 2015-03-05, Information-Centric Networks (ICN) provide substantial flexibility for users to obtain information without regard to the source of the information or its current location. Publish/subscribe (pub/sub) systems have gained popularity in society to provide the convenience of removing the temporal dependency of the user having to indicate an interest each time he or she wants to receive a particular piece of related information. Such an "information-centric" communication model should be supported in the new ICN network paradigm. This document outlines some research directions for ICN with respect to enhancing the inherently pull-based ICN approaches for achieving efficient pub/sub capability. "TCP Use TLS Option", Eric Rescorla, 2015-07-06, This document defines a TCP option (TCP-TLS) to indicate that TLS should be negotiated on a given TCP connection. "Auto-attach using LLDP with IEEE 802.1aq SPBM networks", Paul Unbehagen, Dan Romascanu, John Seligson, Carl Keene, Nigel Bragg, Ludovic Beliveau, 2015-01-13, This informational document describes a compact method of using IEEE 802.1AB Link Layer Discovery Protocol (LLDP) with IEEE 802.1aq Shortest Path Bridging (SPB) network to automatically attach network devices not supporting IEEE 802.1ah to individual services in a SPB network. These network devices typically do not support SPBM, MAC- in-MAC (802.1ah), nor I-SID usage and therefore cannot easily take advantage of the SPB infrastructure without manual configuration of attachment of VLANs to I-SIDs in multiple locations. A motivation for this draft is to suggest a useful means to simplify and automate connections to PBB L2VPN based service networks such as those defined in SPBM-EVPN "Distributed Mobility Management Protocol for WiFi Users in Fixed Network", Behcet Sarikaya, Li Xue, 2015-07-02, As networks are moving towards flat architectures, a distributed approach is needed to mobility management. This document defines a distributed mobility management protocol called Distributed Mobility Management for Wi-Fi protocol. The protocol is based on mobility aware virtualized routing system with software-defined network support. Routing is in Layer 2 in the access network and in Layer 3 in the core network. Smart phones access the network over IEEE 802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise buildings. "Fault Management in Service Function Chaining", Yuanlong Jiang, Weiping Xu, Zhen Cao, 2015-07-06, This document specifies some Fault Management tools for SFC. It also describes the procedures of using these tools to perform connectivity verification and SFP tracing functions upon SFC services. "CGA SEC Option for Secure Neighbor Discovery Protocol", Sheng Jiang, Dacheng Zhang, Suresh Krishnan, 2015-01-15, A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. It is a vital component of Secure Neighbor Discovery (SeND) protocol. The current SeND specifications are lack of procedures to specify the Sec bits. A new SEC option is defined accordingly to address this issue. "Stateful Path Computation Element (PCE) Inter-domain Considerations", Dhruv Dhody, Xian Zhang, 2015-01-15, A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations will be described in a separate document. "Requirements for a Service Description Language and Design Considerations", Yinben Xia, Sheng Jiang, Susan Hares, 2015-05-04, The more and more complicated IP networks require a new interaction mechanism between their customers and their networks. A service description language is needed to enable customers to easily describe their diverse intent. SDN controller would compile the user intent into device configurations. This document analyzes requirements for such service description language and gives considerations for designing such service description language. "NEMO (NEtwork MOdeling) Language", Yinben Xia, Sheng Jiang, Tianran Zhou, Susan Hares, 2015-05-04, The North-Bound Interface (NBI), located between the control plane and the applications, is essential to enable the application innovations and nourish the eco-system of SDN. While most of the NBIs are provided in the form of API, this document proposes the NEtwork MOdeling (NEMO) language which is intent based interface with novel language fashion. Concept, model and syntax are introduced in the document. "PCEP Best Current Practices - Message formats and extensions", Ramon Casellas, Oscar Gonzalez de Dios, Adrian Farrel, Cyril Margaria, Dhruv Dhody, Xian Zhang, 2015-04-27, A core standards track RFC defines the main underlying mechanisms, basic object format and message structure of the Path Computation Element (PCE) Communications Protocol (PCEP). PCEP has been later extended in several RFCs, focusing on specific functionalities. The proliferation of such companion RFCs may cause ambiguity when implementing a PCE based solution. This document aims at documenting best current practices and at providing a reference RBNF grammar for PCEP messages, including object ordering and precedence rules. "NVE Auto-Discovery Protocol", Zhongyu Gu, Ting Ao, Chongfeng Xie, Vic Liu, 2015-01-04, NVO3 provides a framework for Network virtualization in data center, and it will include a series of protocols. This document describes the NVO3 NVE automatic discovery protocol, and shows how VN can be configured and how VM joins VN automatically. "Virtual Network Auto-Provisioning Requirements", Zhongyu Gu, Ting Ao, Qiong, Vic Liu, 2015-01-04, [RFC7365] and [RFC7364] all have some information on "Auto- provisioning/Service discovery" or "Dynamic Provisioning". Some further information should be helpful to clarify how automatic virtual network/service provisioning can be done in NVO3 partially if total automatic service provisioning is difficult. This document describes the NVO3 general virtual network provisioning processes and discusses how VN can be automatically provided and related requirements in or out of the scope of NVO3. "The OAuth 2.0 Internet of Things (IoT) Client Credentials Grant", Hannes Tschofenig, 2015-03-08, As Internet of Things (IoT) deployments increase steadily the need for a better user experience for handling the authentication and authorization tasks in constrained environments increases. While several technologies have been developed already that allow federated access to protected resource the nature of IoT deployments requires care with the limited resources available on many of these devices. This document defines a new OAuth 2.0 authorization grant for the interaction between constrained clients and resource servers to obtain access tokens for access to protected resources. It does so by leveraging prior work on OAuth 2.0, CoAP, and DTLS. "The OAuth 2.0 Bearer Token Usage over the Constrained Application Protocol (CoAP)", Hannes Tschofenig, 2015-03-08, This specification describes how to use OAuth 2.0 bearer tokens to access protected resources using the Constrained Application Protocol (CoAP). Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. "LISP-OAM (Operations, Administration and Management): Use cases and requirements", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Marc Portoles-Comeras, Michael Kowal, Darrel Lewis, Fabio Maino, 2015-05-01, This document describes Operations Administration and Management (OAM) use-cases and the requirements that they have towards the LISP architecture. "Running Multiple PLATs in 464XLAT", Qiong, Zhirong Zhang, Qin Zhao, Sheng Jiang, XiaoDong Lee, Yu Fu, 2015-06-25, The IPv6 transition has been an ongoing process throughout the world due to the exhaustion of the IPv4 address space. The 464XLAT [RFC6877] provides a solution with limited IPv4 connectivity across an IPv6-only network, and the android system (version 2.3 and above) has already implemented the 464XLAT and the Prefix discovery solution [RFC7050]. However, the current 464XLAT architecture can only deal with the scenario with single PLAT in the network. When operator deploys multiple PLATs with different Pref64 prefixes, 464XLAT cannot cope with multiple prefixes for different destination addresses. This document describes the architecture with multiple PLATs and also the deployment considerations. "Internet Measurement System", m.ooki@ntt.com, Satoshi Kamei, 2015-06-21, This document describes an experience of Japanese Internet measurement system to measure end-to-end performance of user's experience. We have developed the system toward the enhancement of the network performance in an ISP since October 2013. The systems and the considerations about the Internet measurement are introduced along with our current status. This document is expected to be useful for the standardization of Internet measurements. "Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT", Anders Lindgren, Fehmi Abdesslem, Bengt Ahlgren, Olov Schelen, Adeel Malik, 2015-07-06, This document outlines the tradeoffs involved in utilizing Information Centric Networking (ICN) for the Internet of Things (IoT) scenarios. It describes the contexts and applications where the IoT would benefit from ICN, and where a host-centric approach would be better. The requirements imposed by the heterogeneous nature of IoT networks are discussed (e.g., in terms of connectivity, power availability, computational and storage capacity). Design choices are then proposed for an IoT architecture to handle these requirements, while providing efficiency and scalability. An objective is to not require any IoT specific changes of the ICN architecture per se, but we do indicate some potential modifications of ICN that would improve efficiency and scalability for IoT and other applications. This document mainly serves as a problem statement and will not present a conclusive architecture design. It can be used as a basis for further discussion and to design architectures for the IoT. "Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery", Sebastian Kiesel, Martin Stiemerling, 2015-07-06, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the algorithm specified in this document takes one IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address. "ALTO Cost Calendar", Sabine Randriamasy, Yang Yang, Wenson Wu, Deng Lingli, Nico Schwan, 2015-07-06, 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 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 also allows to schedule the ALTO requests themselves and thus save a number of ALTO transactions. The 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. "Transporting CoAP Messages over IEEE802.15.4e Information Elements", Qin Wang, Xavier Vilajosana, Thomas Watteyne, Raghuram Sudhaakar, Pouria Zand, 2015-07-02, This document describes the format of "CoAP IE", an IEEE802.15.4e Information Element which allows CoAP messages to be transported as part of the IEEE802.15.4e payload IE. This enables 6top-to-6top communication between neighbor nodes in a 6TiSCH network. "Minimal Incremental Zone Transfer in DNS", W. Mekking, Ólafur Guðmundsson, 2015-01-15, This document proposes extensions to the DNS protocol to provide an incremental zone transfer (IXFR) mechanism with dynamic update (UPDATE) capabilities, to keep IXFRs that deal with DNSSEC small. "Summary of I2RS Use Case Requirements", Susan Hares, Mach Chen, 2015-05-14, The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. "Fundamental Elliptic Curve Cryptography Algorithms", David McGrew, Kevin Igoe, Margaret Salter, Paul Hoffman, 2015-06-29, This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This version of the note incorporates errata that were reported on RFC 6090 [RFC6090]. "Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)", Thomas Dreibholz, 2015-07-05, This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. "REST Style Large MeAsurement Platform Protocol", Vic Liu, Deng Lingli, Dapeng Liu, Shu Liu, Cathy Li, 2015-05-06, This document defines and implements a LMAP protocol based on YANG Model and Rest-style http for control and report in Large Scale Performance Measurement (LMAP). "Congestion Control Using FEC for Conversational Media", Varun Singh, Marcin Nagy, Joerg Ott, Lars Eggert, 2015-04-30, This document describes a new mechanism for conversational multimedia flows. The proposed mechanism uses Forward Error Correction (FEC) encoded RTP packets (redundant packets) along side the media packets to probe for available network capacity. A straightforward interpretation is, the sending endpoint increases the transmission rate by keeping the media rate constant but increases the amount of FEC. If no losses and discards occur, the endpoint can then increase the media rate. If losses occur, the redundant FEC packets help in recovering the lost packets. Consequently, the endpoint can vary the FEC bit rate to conservatively (by a small amount) or aggressively (by a large amount) probe for available network capacity. "Delegated CoAP Authentication and Authorization Framework (DCAF)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, 2015-03-09, This specification defines a protocol for delegating client authentication and authorization in a constrained environment for establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS to transfer authorization information and shared secrets for symmetric cryptography between entities in a constrained network. A resource- constrained node can use this protocol to delegate authentication of communication peers and management of authorization information to a trusted host with less severe limitations regarding processing power and memory. "Support for adjustable maximum router lifetimes per-link", Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko, 2015-07-06, 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. "Delay-based Congestion Control for MPTCP", Mingwei Xu, Yu Cao, Enhuan Dong, 2015-07-05, This document describes the mechanism of wVegas (weighted Vegas), which is a delay-based congestion control for MPTCP. The current congestion control algorithm of MPTCP, LIA, achieves only course- grained load balancing, since it is based on packet loss event. On the contrary, wVegas adopts packet queuing delay as congestion signals, thus achieving fine-grained load balancing. Compared with loss-based algorithms, wVegas is more sensitive to the changes of network congestion and thus achieves more timely traffic shifting and quicker convergence. WVegas has been implemented in the Linux Kernel and is part of the UCLouvain's MPTCP implementation now. "TCP SYN Extended Option Space Using an Out-of-Band Segment", Joseph Touch, Ted Faber, 2015-04-15, This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. "Correlation of multiple responses of forked INVITES in Back to Back User Agents", Roland Jesske, 2015-03-03, This document describe the scenarios where multiples early dialogs can be created. The main use case is based on forking. But also forwarding of SIP Invites and other applications may create early dialogs. The scenarios shown describe how a correlation/multiplexing of multiple early dialogs caused by forked or forwarded INVITEs in Back to Back User Agents can apply. Existing RFC's are analyzed how forking is described and points to facts which may be taken in to consideration. "Balanced Linked Adaptation Congestion Control Algorithm for MPTCP", Anwar Walid, Qiuyu Peng, Jaehyun Hwang, Steven Low, 2015-01-27, This document describes the mechanism of Balia, the "Balanced linked adaptation", which is a congestion control algorithm for Multipath TCP (MPTCP). The recent proposals, LIA and OLIA, suffer from either unfriendliness to Single Path TCP (SPTCP) or unresponsiveness to network changes under certain conditions. The tradeoff between friendliness and responsiveness is inevitable, but Balia judiciously balances this tradeoff based on a new design framework that allows one to systematically explore the design space. Balia has been implemented in the Linux kernel and also included in the UCLouvain's MPTCP implementation. "IDNA Update for Unicode 7.0.0", John Klensin, Patrik Fältström, 2015-03-11, The current version of the IDNA specifications anticipated that each new version of Unicode would be reviewed to verify that no changes had been introduced that required adjustments to the set of rules and, in particular, whether new exceptions or backward compatibility adjustments were needed. The review for Unicode 7.0.0 first identified a potentially problematic new code point and then a much more general and difficult issue with Unicode normalization. This specification discusses those issues and proposes updates to IDNA and, potentially, the way the IETF handles comparison of identifiers more generally, especially when there is no associated language or language identification. It also applies an editorial clarification to RFC 5892 that was the subject of an earlier erratum and updates RFC 5894 to point to the issues involved. "Path Computation Element communication Protocol extension for relationship between LSPs and Attributes", Dhruv Dhody, Wenson Wu, 2015-07-05, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document defines a mechanism to create associations between a set of LSPs and a set of attributes (such as configuration parameters, policy or behaviours). "Bloom Filter-based Flat Name Resolution System for ICN", jhong@etri.re.kr, Woo-Jik Chun, Hee Jung, 2015-07-06, In information-centric networking (ICN), uniquely identifiable and location independent names are assigned directly to the named data which raises scalability issues and they get even worse with flat names. Accordingly, name resolution system required for lookup-by- name routing in ICN has to be designed to scale, also considering mobility support. In this draft, a bloom filter-based flat name resolution system (B-NRS) is proposed where the bloom filter as an aggregated form of names and hierarchical structure of the B-NRS are exploited to address the scalability issues. "HTTP/2 Priority Tree Synchronization", Herve Ruellan, Youenn Fablet, Romain Bellessort, Jun Fujisawa, 2015-01-22, This specification describes an issue in HTTP/2 linked to the synchronization of priority trees between a client and a server. It outlines possible solutions to this issue. "BGP Path Record Attribute", Robert Raszuk, Russ White, Jie Dong, 2015-04-26, The BGP protocol contains number of built in mechanisms which records information about the routers which have processed a specific piece of reachability information critical to insuring only loop free paths are chosen by the protocol. For instance, the AS_PATH, CLUSTER_LIST and ORIGINATOR_ID attributes carry information designed to insure permanent routing loops are not formed in the path chosen towards a particular destination. However, there are no provisions to record other useful information along the path, metadata about the routers through which reachability information has passed which can be helpful to the operator in order to enhance end to end visibility of the BGP control plane. In order to solve this problem this document proposes a new single BGP attribute designed as an generic and extensible container to carry number of new optional information corresponding to the BGP speakers given BGP advertisement (or withdraw) message traverses. "Qualifying Questions for a CoAP Advanced Congestion Control Scheme", Carsten Bormann, 2015-03-09, CoAP (RFC7252) comes with a conservative base congestion control scheme. Advanced congestion control schemes can be defined where better performance is desired for a certain area of application. This document is a strawman for a set of questions that could be used in qualifying a CoAP advanced congestion control scheme. "HTTP/2 Segments", Matthew Kerwin, 2015-02-16, This document introduces the concept of "segments" to HTTP/2, and adds a flag to the DATA frame type to allow the expression segments. A "segment" is a contiguous block of HTTP message data that can be freely split apart and recombined at any time, allowing transmission in multiple HTTP/2 frames across network segments with smaller frame size limits without risk of permanent fragmentation when traversing network segments with much larger limits. "Advertising Tunnelling Capability in IS-IS", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2015-06-30, Some networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the ingress needs to select a type of tunnel which is supported by the egress. This document defines how to advertise egress tunnel capabilities in IS-IS Router Capability TLV. "OAuth 2.0 Token Exchange: an STS for the REST of us", Brian Campbell, J. Bradley, 2015-02-02, An OAuth 2.0 framework for exchanging security tokens enabling authorization servers to act as lightweight HTTP and JSON based security token services. "Network Service Header (NSH) Context Header Allocation (Data Center)", Jim Guichard, Michael Smith, Surendra, Sumandra Majee, Puneet Agarwal, Kevin, Youcef Laribi, 2015-06-15, This document provides a recommended default allocation for the fixed context headers within a Network Service Header (NSH). NSH is defined in [I-D.quinn-sfc-nsh]. The allocation scheme is relevant when NSH is used for Service Function Chaining within a data center and may be used to support use cases such as those described in [I-D.ietf-sfc-dc-use-cases]. "TCP Stealth", Julian Kirsch, Christian Grothoff, Jacob Appelbaum, Holger Kenn, 2015-01-17, TCP servers are visible on the Internet to unauthorized clients, as the existence of a TCP server is leaked in the TCP handshake before applications have a chance to authenticate the client. We present a small modification to the initial TCP handshake that allows TCP clients to replace the TCP ISN in the TCP SYN packet with an authorization token. Based on this information, TCP servers may then chose to obscure their presence from unauthorized TCP clients. This RFC documents the specific method for calculating the authorization token to ensure interoperability and to minimize interference by middleboxes. Mandating support for this method in operating system TCP/IP implementations will ensure that clients can connect to TCP servers protected by this method. "EdDSA for OpenPGP", Werner Koch, 2015-03-04, This specification extends OpenPGP with the EdDSA public key algorithm and describes the use of curve Ed25519. "Representing DNS Messages in JSON", Paul Hoffman, 2015-04-27, Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search those without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a standardized format for DNS message data in JSON. "RFC Format Framework", Heather Flanagan, 2015-06-21, 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, with different publication formats 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. "Proof-based Authentication for HTTP Messages", Manu Sporny, 2015-06-27, For a client to access a particular resource on the Web, a server must expend a certain amount of computational effort to respond to the request. In some cases this computational effort is sizeable and the server may want to only respond to certain clients. For example, in a distributed denial-of-service attack, a server may require all clients to expend a certain amount of resources via a client-run proof-of-work algorithm to throttle the number of incoming requests to a more manageable number. This document details a new authentication scheme for HTTP that may be used to request and transmit proofs in HTTP headers. "Network Ingress Filtering: Defeating Attacks which employ Forged ICMP/ ICMPv6 Error Messages", Fernando Gont, Ray Hunter, Jeroen, Shucheng LIU, 2015-03-08, Over the years, a number of attack vectors that employ forged ICMP/ ICMPv6 error messages have been disclosed and exploited in the wild. The aforementioned attack vectors do not require that the source address of the packets be forged, but do require that the addresses of the IP/IPv6 packet embedded in the ICMP/ICMPv6 payload be forged. This document discusses a simple, effective, and straightforward method for using ingress traffic filtering to mitigate attacks that use forged addresses in the IP/IPv6 packet embedded in an ICMP/ICMPv6 payload. This advice is in line with the recommendations in BCP38. "OpenPGP Extensions for Device Certificates", Derek Atkins, 2015-06-09, The OpenPGP Message Formats defined in RFC 4880 specify packet formats and methods for combining those packets to form messages and certificates. However RFC 4880 made an architectural decision that keys are owned by users and must be self-certified. New use cases have emerged where that is not the case. There is a desire to have certificates that are not tied to a user (e.g. device certificates) which may only have encryption keys so may not be self certifiable. Moreover, devices might be space constrained so reducing size is important. This draft specifies extensions to (and updates) RFC 4880 that loosen the definitions of certificates in order to enable userless certificates without self-certifications and specifies a set of notations to enable compact device certifications. "Transmission and Processing of IPv6 Options", Fernando Gont, Shucheng LIU, Ron Bonica, 2015-03-09, Various IPv6 options have been standardized since the core IPv6 standard was first published. This document updates RFC 2460 to clarify how nodes should deal with such IPv6 options and with any options that are defined in the future. It complements [RFC7045], which offers a similar clarification regarding IPv6 Extension Headers. "DNS Name Autoconfiguration for Internet of Things Devices", Jaehoon Jeong, Park Jung-Soo, 2015-07-06, This document specifies an autoconfiguration scheme for DNS names of Internet of Things (IoT) devices, such as appliances and sensors. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's category and model in wired and wireless networks (e.g., home, office, shopping mall, smart grid, and road network). This DNS name lets IoT users (e.g., home residents and customers) easily identify each device for monitoring and remote-controlling it in a target network. "SPRING Use cases for IP Flow Mobility", Jeong Kim, 2015-01-12, The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed'. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. "Application-Level Profile Semantics (ALPS)", Mike Amundsen, Leonard Richardson, Mark Foster, 2015-03-02, This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application- agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Media-Types mailing list (see [1]). "Extensions to OSPF for Advertising Prefix/Link Administrative Tags", Acee Lindem, Peter Psenak, 2015-03-30, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130. "A TCP and TLS Transport for the Constrained Application Protocol (CoAP)", Carsten Bormann, Simon Lemay, Zebra Technologies, Hannes Tschofenig, 2015-06-10, The Hypertext Transfer Protocol (HTTP) has been designed with TCP as an underlying transport protocol. The Constrained Application Protocol (CoAP), which has been inspired by HTTP, has on the other hand been defined to make use of UDP. Therefore, reliable delivery and a simple congestion control and flow control mechanism are provided by the message layer of the CoAP protocol. A number of environments benefit from the use of CoAP directly over a reliable byte stream that already provides these services. This document defines the use of CoAP over TCP as well as CoAP over TLS. "Source Address Dependent Routing and Source Address Selection for IPv6 Hosts: Problem Space Overview", Behcet Sarikaya, Mohamed Boucadair, 2015-06-09, This document presents the source address dependent routing (SADR) problem space from the host perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next hop resolution in view of source address dependent routing is needed. "IPPM Considerations for the IPv6 PDM Destination Option", Nalini Elkins, Rob, Michael Ackermann, 2015-02-15, 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 has been proposed in a companion document. This document specifies the field limits, calculations, and usage of the PDM in measurement. "Using Algebraic Eraser (AEDH) in OpenPGP", Derek Atkins, 2015-06-18, The Algebraic Eraser(TM) is an encryption engine that supports, among other configurations, a Diffie-Hellman-like key agreement protocol. This draft specifies how to encode, store, share, and use Algebraic Eraser Key Agreement Protocol (AEKAP, also called AEDH) keys in OpenPGP. "Privacy Choices for Internet Data Services", Tim Bray, 2015-04-11, This document argues in favor of Internet service providers deploying technologies which offer increased privacy to users of their services. The discussion is independent of any particular privacy technology. The approach is to consider common objections to the the deployment of such technologies, and show that these objections are not well-founded. "Initial Performance Metric Registry Entries", Al Morton, Marcelo Bagnulo, Philip Eardley, 2015-03-09, This memo defines the Initial Entries for the Performance Metrics Registry. "Detection of Primary Server Failure in DHCPv6 Failover", Lanshan Zhang, Wendong Wang, Yuchi Chen, Linhui Sun, 2015-05-06, In DHCPv6 failover or other multiple servers deployment scenarios, an automatic failure detection capability may be desirable. This document describes a detection method, with which the secondary server can detect the link failure between the primary server and clients. This document does not define any protocol details. "DNS Delete-Confirm Mechanism with Multi-DHCP-Servers", Xirong Que, Wenhong Wang, Lanshan Zhang, Linhui Sun, 2015-04-15, [I-D.ietf-dhc-addr-registration] specifies how a host register its self-generated addresses in DNS through DHCPv6 server. [RFC3315] allows multiple DHCPv6 servers working in an administrative domain. There exists a scenario that the client may register its addresses in multiple servers for some reasons such as higher availability and etc. This document defines a mechanism to ensure the multiple servers could work properly during updating DNS. "Use Case for Distributed Data Center in SUPA", Ying Cheng, Dacheng Zhang, JF Tremblay, Alibaba Group, Jun Bi, Luis Contreras, 2015-06-30, Large scale Distributed Data Centers (DDCs) can provide various services and usually consist of numbers of internal and external links where various VPNs are built upon. The Service provisioning and network connectivity configurations could be complex and dynamic, and manual configuration is onerous and error-prone. This draft analyzes the use cases in DDCs, in which some VPN scenarios are covered, and the applicability of Simplified Use of Policy Abstractions (SUPA) data models which can be used for better and automated resource usage and easy service/network deployment/ configuration. "A YANG Data Model for Network Topologies", Luis Contreras, Jun Bi, Andrew Qu, Yiyong Zha, 2015-02-06, This document defines a YANG data model for network topologies. "IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.", Suhas Nandakumar, 2015-05-02, RTP provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The RTP specification [RFC3550] establishes a registry of profile names for use by higher-level control protocols, such as the SDP, to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. "OSPF Extensions for Flow Specification", Qiandeng Liang, Jianjie You, Nan Wu, Peng Fan, Keyur Patel, Acee Lindem, 2015-05-28, Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., OSPF), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes. This document discusses the use cases for distributing flow specification (FlowSpec) routes using OSPF. Furthermore, this document defines a OSPF FlowSpec Opaque Link State Advertisement (LSA) encoding format that can be used to distribute FlowSpec routes, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. "SPRING OpenFlow Interworking Requirements", fangwei hu, Bhumip Khasnabish, Hakki Cankaya, 2015-03-09, This draft reviews the use cases and lists the requirements for interworking (IW) between OpenFlow (OF) and Segment routing (SR). Although the details and specifics of IW depend on both the architecture and framework, there are some common requirements. We specify those common requirements and show a simple architecture framework. "LISP RLOC Membership Distribution", Christian Cassar, Isidor Kouvelas, Johnson Leong, Darrel Lewis, Gregg Schudel, 2015-03-27, The Locator/ID Separation Protocol (LISP) operation is based on EID to RLOC mappings that are exchanged through a mapping system. The mapping system can use the RLOCs included in mapping registrations to construct the complete set of RLOC addresses across all xTRs that are members of the LISP deployment. This set can then be made available by the mapping system to all the member xTRs. An xTR can use the RLOC set to optimise protocol operation as well as to implement new functionality. This document describes the use of the LISP reliable transport session between an xTR and a Map-Server to communicate the contents of the RLOC membership set. "Problem Statement for Simplified Use of Policy Abstractions (SUPA)", Georgios Karagiannis, John Strassner, Qiong, Luis Contreras, Parviz Yegani, Jun Bi, 2015-06-07, The increase in complexity of modern networks makes it challenging to deploy new services and to keep networks up to date whilst maintaining stability and availability for critical business services. This is a major challenge that network operators (service providers, SME, etc) face today. The operators aim of streamlining both operations and the deployment of new services, is being met by increasingly relying on (1) software abstractions to simplify the design and configuration of monitoring and control operations and (2) the use of programmatic control over the configuration and operation of such networks. In this context, providing network operators with a generic policy- based management model that can be used to express policies on top of arbitrary configuration data models is essential. In particular, SUPA addresses the needs of operators and application developers to use a generic policy-based management model for defining and representing multiple types of policy rules. "Simplified Use of Policy Abstractions (SUPA): Configuration and Policy Mapping", Kostas Pentikousis, Dacheng Zhang, 2015-05-11, Nowadays, the underlying network infrastructure grows in scale and complexity, which make it challenging for network operators to manage and configure the network. Deploying policy or configuration based on an abstract view of the underlying network is much better than manipulating each individual network element, however, in this case, the policy and configuration cannot be recognized by the network elements. This document describes guidelines for mapping said abstract configuration and policy into device-level configuration and the way in which such models will be processed by software to produce configuration details for actual devices. The Simplified Use of Policy Abstractions (SUPA) framework overview, exemplary mechanism for exchanging service polices among the different elements participating in their deployment and enforcement, and primary procedures of mapping are described. Moreover, an exemplary mapping scenario is provided to illustrate the defined mechanism. "YANG Data Model for MPLS-TP Operations, Administration, and Maintenance (OAM)", Li Zhang, Lianshu Zheng, Sam Aldrin, Greg Mirsky, 2015-07-03, The Transport Profile of Multiprotocol Label Switching (MPLS-TP) [RFC5921]is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. A comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management had been defined. YANG [RFC6020]is a data definition language that was introduced to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241]. This document presents the YANG Data model for MPLS-TP OAM, including the basic functions of Fault Management and Performance Monitoring. "IS-IS Extensions for Flow Specification", Jianjie You, LQD, Keyur Patel, Peng Fan, 2015-06-29, Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., IS-IS), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes. This document discusses the use cases for distributing flow specification (FlowSpec) routes using IS-IS. Furthermore, this document defines a new IS-IS FlowSpec Reachability TLV encoding format that can be used to distribute FlowSpec routes, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. "Requirements for Peer Mounting of YANG subtrees from Remote Datastores", Eric Voit, Alex Clemm, Sander Mertens, 2015-03-10, Network integrated applications want simple ways to access YANG objects and subtrees which might be distributed across network. Performance requirements may dictate that it is unaffordable for a subset of these applications to go through existing centralized management brokers. For such applications, development complexity must be minimized. Specific aspects of complexity developers want to ignore include: o whether authoritative information is actually sourced from remote datastores (as well as how to get to those datastores), o whether such information has been locally cached or not, o whether there are zero, one, or more controllers asserting ownership of information, and o whether there are interactions with other applications concurrently running elsewhere The solution requirements described in this document detail what is needed to support application access to authoritative network YANG objects from controllers (star) or peering network devices (mesh) in such a way to meet these goals. "Responsibility for Authoritative DNSSEC Mistakes", Jason Livingood, 2015-05-06, DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. Authoritative DNS operators should focus on improving these processes and establishing a high level of quality in their work. "In Case of DNSSEC Validation Failures, Do Not Change Resolvers", Jason Livingood, 2015-05-06, DNS Security Extensions (DNSSEC) are being widely deployed, particularly via validating resolvers. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. As a result, some DNSSEC validation failures may occur. When these failures do occur, end users should not change to a non-validating DNS resolver. "Advertising LSPs with Segment Routing", Chris Bowers, Hannes Gredler, Uma Chunduri, 2015-03-09, Segment routing uses globally-known labels to accomplish forwarding along shortest paths, and label stacks to accomplish explicit routing along arbitrary paths. These labels are advertised using an IGP. This draft describes how label bindings corresponding to RSVP, LDP, BGP labeled-unicast, and static LSPs are advertised in segment routing and how these labels can be combined with other segment routing labels to create forwarding paths. This draft also describes how context labels for egress node protection are advertised in using segment routing IGP extensions. "Interface to Network Security Functions (I2NSF) Problem Statement", Linda Dunbar, Myo Zarny, Christian Jacquenet, Mohamed Boucadair, Shaibal Chakrabarty, 2015-05-28, This document describes the motivation and the problem statement for Interface to Network Security Functions (I2NSF). "IPv4/IPv6 Transition Practice in OpenStack", Yi Bai, Congxiao Bao, Kevin Yin, Xing Li, 2015-03-26, OpenStack is a free and open-source software cloud computing platform. It is primarily deployed as an infrastructure as a service (IaaS) solution. However, OpenStack is designed mainly for IPv4, it internally uses [RFC1918] addresses and heavily relies on NAT to map RFC1918 addresses to public IPv4 addresses known as floating IP addresses for the external access. Due to the different nature of IPv6 and IPv4, the IPv6 support for the OpenStack is still in the early stage. In this document, two mechanisms are presented to provide IPv4/IPv6 dual stack external access for the OpenStack, one scenario is internal IPv4 and uses stateful IPv4/IPv6 translator for the external IPv6 access, and another scenario is internal IPv6 and uses stateless IPv4/IPv6 translation for the external IPv4 access. Both mechanisms have been deployed in CERNET and providing services to the global IPv4/IPv6 Internet. "Service Function Chaining Using MPLS-SPRING", Xiaohu Xu, Zhenbin Li, Himanshu Shah, Luis Contreras, 2015-03-08, Source Packet Routing in Networking (SPRING) WG specifies a special source routing mechanism. Such source routing mechanism can be leveraged to realize the service path layer functionality of the service function chaining (i.e, steering traffic through a particular service function path) by encoding the service function path or the service function chain information as the explicit path information. This document describes how to leverage the MPLS-based source routing mechanism as developed by the SPRING WG to realize the service path layer functionality of the service function chaining. "Simplified Use of Policy Abstractions (SUPA) Gap Analysis", Jun Bi, Hosnieh Rafiee, Vikram Choudhary, John Strassner, Dan Romascanu, 2015-05-20, As operators struggle to optimize their network for different applications while maximizing network resources usage, there's growing business pressure to minimize operational tasks and the deployment time of new services. New automation paradigms are meant to help reach these goals, including the optimization of network functions through application control. This control could be signaled directly by an application, through a proxy or orchestrated in a centralized manner. The purpose of SUPA is to develop a methodology by which network services can be managed using standardized policy rules. SUPA will focus in the first phase on inter-datacenter traffic management as part of the distributed data center use case, including the automated provisioning of site-to-site virtual private networks of various types.This memo analyses the current state of the art of the industries in IETF and outside IETF. "Gap Analysis for Layer and Technology Independent OAM Management in the Multi-Layer Environment", Yuji Tochio, Huub van Helvoort, Liang Xia, 2015-04-27, This draft analyses the existing management plane OAM related works in different SDOs, against the key objectives of Layer Independent OAM Management (LIME), to find the gap between them. The results can be used as the guidance for further work. This gap analysis is not targeted at L0-L2 transport OAM in ITU-T, either technology specific or generic across those technologies. Rather, it is intended to leverage knowledge from that domain for the benefit of developing generic layer independent OAM management for L3-L7 (and L2.5 MPLS OAM). "Deterministic Networking Problem Statement", Norman Finn, Pascal Thubert, 2015-06-11, This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties . "An Information Model for Basic Network Policy and Filter Rules", Susan Hares, Qin Wu, Jeff Tantsura, Russ White, 2015-03-08, This document contains the Basic Network Policy and Filters (BNP IM) Information Model which provides a generic model for representing an ordered list of routing policy or filter rules. Filter rules which combine match-condition with action (forwarding or sets) are supported by this policy. "BIER Encapsulation", Xiaohu Xu, Somasundaram, Christian Jacquenet, Robert Raszuk, 2015-02-25, Bit Index Explicit Replication (BIER) is a new multicast forwarding paradigm which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. This document proposes a transport-independent BIER encapsulation header which is applicable in any kind of transport networks. "Adding Support for Salted Password Databases to EAP-pwd", Dan Harkins, 2015-01-08, EAP-pwd is an EAP method that uses a shared password for authentication using a technique that is resistant to dictionary attack. It included support for raw keys and RFC2751-style double hashing of a password but did include support for salted passwords. There are many existing databases of salted passwords and it is desirable to allow their use with EAP-pwd. "OAuth 2.0 Introspection over the Constrained Application Protocol (CoAP)", Erik Wahlstroem, 2015-03-09, This document defines a method for a client or resource server to query an OAuth authorization server to determine meta- information about an OAuth token using the Constrained Application Protocol (CoAP) [4]. An client in possession of a OAuth2 token can use it to get metadata about the token like validity and approved scopes. "Autonomic Networking Definitions Revisited", Kostas Pentikousis, Manolis Sifalakis, Jeff, 2015-05-04, This document revisits the autonomic networking terminology established in peer-reviewed literature, aiming to contribute to the ongoing discussion in the IRTF NMRG about how to move forward with standardizing various autonomic networking aspects. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 2015-03-29, This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version. "Dissemination of Flow Specification Rules for IPv6 Implementation Report", Gunter Van de Velde, Wim Henderickx, Nicolas Fevrier, Andy, Ashutosh Grewal, 2015-07-02, This document is an implementation report for the BGP Flow Specification Rules for IPv6 as defined in [I-D.ietf-idr-flow-spec-v6]. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. "Resource Attributes for ALTO Protocol", Wendy Roome, 2015-04-10, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by defining additional descriptive attributes for the resources offered by an ALTO Server. "Allocation Token Extension for the Extensible Provisioning Protocol (EPP)", James Gould, Trung Tran, Sharon Wodjenski, 2015-03-02, This document describes an Extensible Provisioning Protocol (EPP) extension for including an allocation token or code for allocating an object like a domain name to the client. The allocation token MAY be transferred out-of-band to a client to give them authorization to allocate an object using one of the EPP transform commands including create, update, and transfer. "Examples of the 'XML2RFC' Version 2 and 3 Vocabularies", Paul Hoffman, Tony Hansen, 2015-05-07, This document gives examples of use of the "XML2RFC" vocabulary. The examples cover both version 2 and version 3. The purposes of this draft is to give developers of tools that process v2 and/or v3 documents a corpus to test against. 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 [1]. "NVA Address Mapping Distribution (NAMD) Protocol", Linda Dunbar, Donald Eastlake, 2015-03-03, This draft describes the protocol for NVA to promptly and incrementally distribute the inner (TS) to outer (NVE) mapping and VN Context to relevant NVEs in a timely manner. "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Dhruv Dhody, Jonathan Hardwick, Vishnu Pavan Beeram, Zafar Ali, Jeff Tantsura, 2015-07-05, This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration data and state data (status information and counters for the collection of statistics). "ICE IPv4/IPv6 Dual Stack Fairness", Paal-Erik Martinsen, Tirumaleswar Reddy, Prashanth Patil, 2015-02-09, 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. "A Generic Discovery and Negotiation Protocol for Autonomic Networking", Brian Carpenter, Bing Liu, 2015-06-20, 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. "Negotiating Human Language in Real-Time Communications", Randall Gellens, 2015-07-05, Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication ("calls") there needs to be a way to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be routed to a Public Safety Answering Point (PSAP) or call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and expected use, and describes a solution using new SDP stream attributes. "NFVIaaS Architectural Framework for Policy Based Resource Placement and Scheduling", Ram (Ramki) Krishnan, Norival Figueira, Dilip Krishnaswamy, Diego Lopez, Steven Wright, Tim Hinrichs, Ruby Krishnaswamy, 2015-03-02, One of the goals of Network Functions Virtualization (NFV) is to offer the NFV infrastructure as a service to other SP customers - this is called NFVIaaS. Virtual Network Function (VNF) deployment in this paradigm will drive support for unique placement policies, given VNF's stringent service level specifications (SLS) required by customer SPs. Additionally, NFV DCs often have capacity, energy and other constraints - thus, optimizing the overall resource usage based on policy is an important part of the overall solution. The purpose of this document is to depict an architectural framework for policy based resource placement and scheduling in the context of NFVIaaS. "IANA Registry Updates for RFC 4566bis", Ali Begen, 2015-01-09, The Session Description Protocol (SDP) specification is currently being revised. There are a number of issues that have been identified in the IANA registries related to the SDP protocol (These are tracked in the issue tracker). This document has the goal of addressing these issues by making the necessary changes in the IANA registries and registration procedures. The changes and updates listed in this draft are submitted in this individual draft rather than the 4566bis draft because (i) the 4566bis draft has seen quite a number of changes recently, which require a detailed review and further revisions would make the review process difficult, and (ii) the changes and updates listed in this draft are all IANA related matters. If this draft gets published separately, it will update RFC 4566 or the RFC resulting from the 4566bis draft. An alternative option is to include the whole text in the 4566bis draft once the changes and updates are agreed. "OSPF for large-scale networks with regular topologies", Anton Smirnov, 2015-04-10, Many popular topologies for large-scale networks have highly regular structure with distinctive design pattern. Examples of such topologies include hub-and-spoke (also known as "star") common in enterprise WAN networks, fat-tree and Clos topologies common in datacenters. For number of reasons in such large-scale networks distance-vector protocols perform better than OSPF. On the other hand network backbones have no highly regular topology pattern and there OSPF outperforms distance-vector protocols. As a result large- scale networks frequently employ different routing protocols in different regions of the network, complicating network operations. This document proposes OSPF extensions to improve scalability of routing for large-scale networks. "Extended procedures and considerations for evaluating Loop-Free Alternates", Uma Chunduri, Jeff Tantsura, Chris Bowers, 2015-03-09, This document provide few clarifications and extended procedures to IP Fast Reroute using Loop-Free Alternates as defined in RFC 5286. "A Reference Model for Autonomic Networking", Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Bing Liu, Jeff, John Strassner, 2015-06-30, 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. "An Autonomic Control Plane", Michael Behringer, Steinthor Bjarnason, Balaji BL, Toerless Eckert, 2015-06-30, 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. One application is a "virtual out of band channel" for communications over a network that is not configured or mis- configured. This document describes requirements and implementation options for an "Autonomic Control Plane". "Protocol Specification Tool", Phillip Hallam-Baker, 2015-07-06, The syntax for the PROTOGEN protocol specification tool is described and the use of the tool to generate protocol specifications, prototype and production implementations. While the primary focus of PROTOGEN is to develop protocols using JSON message syntax, the PROTOGEN framework has been successfully applied to generate prototypes using ASN.1, TLS, XML and RFC822 style syntax. "A Model for IPv6 Operation in OpenStack", Fred Baker, Chris Marino, Ian Wells, Rohit Agarwalla, Sebastian Jeuk, Gonzalo Salgueiro, 2015-02-08, This is an overview of a network model for OpenStack, designed to dramatically simplify scalable network deployment and operations. Requirements Language The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119]. Design Principle Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery "Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))", Simon Perreault, Tina Tsou, Senthil Sivakumar, Tom Taylor, 2015-07-06, This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NAT-MIB-V2, which responds to deficiencies found in module NAT-MIB and adds new capabilities. This document obsoletes RFC 4008. All RFC 4008 MIB objects are included in this version unchanged with only the STATUS changed to deprecated. "YANG Data Model for IPv4-in-IPv6 Softwire", Qi Sun, Hao Wang, Yong Cui, Ian Farrer, Mohamed Boucadair, Rajiv Asati, 2015-04-07, This document defines a YANG data model for the configuration and management of IPv4-in-IPv6 Softwire Border Routers and Customer Premises Equipment. It covers Lightweight 4over6, MAP-E and MAP-T Softwire mechanisms. "Destination/Source Routing", David Lamparter, 2015-06-27, This note specifies using packets' source addresses in route lookups as additional qualifier to be used in route lookup. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. "IPv6 Flow Label Reflection", Aijun Wang, Sheng Jiang, 2015-03-08, The current definition of the IPv6 Flow Label focuses mainly on how the packet source forms the value of this field and how the forwarder in-path treats it. In network operations, there are needs to correlate an upstream session and the corresponding downstream session together. This document propose a flow label reflection mechanism that network devices copy the flow label value from received packets to the corresponding flow label field in return packets. This mechanism could simplify the network traffic recognition process in network operations and make the policy for both directions of traffic of one session consistent. "YANG Data Model for NVO3 Protocols", Mingui Zhang, Lianshu Zheng, Feng Zheng, Fu Qiao, 2015-05-08, This document describes the base YANG data model that can be used by operators to configure and manage NVO3 protocols. "Virtual Network Transport Protocol (VNTP)", Zhongyu Gu, 2015-04-10, This document describes the overlay virtual network transport protocol (VNTP), which defines the interactions between NVE and NVA/ NVE and the relevant message to support virtual network implementation. "Considerations for protecting Email header with S/MIME", Alexey Melnikov, 2015-04-03, This document describes best practices for handling of Email header protected by S/MIME. It also adds a new Content-Type parameter to help distinguish an S/MIME protected forwarded message from an S/MIME construct protecting message header. "IANA Charset Registration Procedures", Mark McFadden, Alexey Melnikov, 2015-04-24, Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046, RFC-2047, RFC-2231) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document obsoletes the IANA Charset Registration Procedures originally defined in [RFC2978]. Specifically, this document completely revises the registration procedures and the charset registries. The charset registry is now divided into three parts with separate registration procedures for each. Note: The charset registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered charset to a particular application is a protocol issue, not a registration issue, and is not dealt with by this registration procedure. "Origin Cookies", Mike West, 2015-04-20, This document updates RFC6265, defining the "origin" attribute for cookies and the "Origin-Cookie" header field, which together allow servers to choose to harmonize the security policy of their cookies with the same-origin policy which governs other available client-side storage mechanisms. "SPRING SID Allocation", Ting Liao, Wu Bo, fangwei hu, Bhumip Khasnabish, 2015-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 and OSPF). And a segment is identified by a Segment Routing ID (SID). This document proposes a method to reduce the SID configuration in a SR domain. Only the selected SR nodes which named Segment Routing Management Nodes (SRMNs) are configured by NMS, while other SRs in the domain need zero-SR-configuration. "IETF Liaisoning", Scott Bradner, 2015-01-22, with peer organizations. In some cases this involves establishing long lasting formal liaison relationships and in other cases the processes are less formal and of shorter duration. The document is designed to be useful in both cases to both IETF participants and to the participants in the other organizations. The document also includes information and pointers to information about the IETF and its operation that may be of use to participants in such peer organizations. "Generic YANG Data Model for Operations, Administration, and Maintenance (OAM)", Tissa Senevirathne, Norman Finn, Deepak Kumar, Samer Salam, Qin Wu, Zitao Wang, 2015-06-01, This document presents base YANG Data model for OAM. It provides a protocol-independent and technology-independent abstraction of key OAM constructs. Based model presented here can be extended to include technology specific details. Leading to uniformity between OAM technologies and support nested OAM workflows (i.e., performing OAM functions at different layers through a unified interface). "Experience with IPv6 path probing", Habib Naderi, Brian Carpenter, 2015-04-21, This document reports on experience and simulations of dynamic probing of alternate paths between two IPv6 hosts when network failures occur. Two models for such probing were investigated: the SHIM6 REAchability Protocol (REAP) and the Multipath Transmission Control Protocol (MPTCP). The motivation for this document is to identify some aspects of path probing at large or very large scale that may be broadly relevant to future protocol design. "YANG Model for Diffserv", Aseem Choudhary, Shitanshu Shah, Mahesh Jethanandani, Bing Liu, Norm Strahle, 2015-06-24, This document describes a YANG model of Differentiated Services for configuration and operations. "Yang Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", Yisong Liu, Feng Guo, 2015-03-23, This document defines a YANG data model that can be used to configure and manage IGMP and MLD. "YANG Data Model for PIM", Yisong Liu, Feng Guo, Mahesh Sivakumar, 2015-03-22, This document defines a YANG data model that can be used to configure and manage PIM. "Parallel NFS (pNFS) SCSI Layout", Christoph Hellwig, 2015-03-23, Parallel NFS (pNFS) extends Network File Sharing version 4 (RFC5661) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS, the pNFS Block/Volume Layout (RFC5663) specifies the additional extensions for use of pNFS with block-and volume-based storage, while this document provides extensions to the pNFS Block/Volume Layout document to provide reliable fencing and better device discoverability for SCSI based shared storage devices. "Unifying Carrier and Cloud Networks: Problem Statement and Challenges", Robert Szabo, Andras Csaszar, Kostas Pentikousis, Mario Kind, Diego Daino, Zu Qiang, Hagen Woesner, 2015-07-06, The introduction of network and service functionality virtualization in carrier-grade networks promises improved operations in terms of flexibility, efficiency, and manageability. In current practice, virtualization is controlled through orchestrator entities that expose programmable interfaces according to the underlying resource types. Typically this means the adoption of, on the one hand, established data center compute/storage and, on the other, network control APIs which were originally developed in isolation. Arguably, the possibility for innovation highly depends on the capabilities and openness of the aforementioned interfaces. This document introduces in simple terms the problems arising when one follows this approach and motivates the need for a high level of programmability beyond policy and service descriptions. This document also summarizes the challenges related to orchestration programming in this unified cloud and carrier network production environment. "Deterministic Networking Uitilities requirements", Patrick Wetterwald, Jean Raymond, 2015-06-30, This paper documents the needs in Smart Grid industry to establish multi-hop paths for characterized flows with deterministic properties. "Handling Incoming Label Request for PW FEC Types", Patrice Brissette, Kamran Raza, Sami Boutros, Nick Regno, Matthew Turlington, 2015-06-29, This document clarifies the behavior of an LSR PE upon receiving an LDP Label Request message for Pseudowire (PW) FEC types. Furthermore, this document specifies the procedures to be followed by the LSR PE in order to answer such requests for a given PW FEC type. "Active and Passive Metrics and Methods (and everything in-between)", Al Morton, 2015-02-24, This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as Active or Passive. Methods can take on some of the attributes of both, and we refer to these as Hybrid Methods. "TCP Four-Way Handshake", David Borman, 2015-03-09, One of the limitations of TCP is that it has limited space for TCP options, only 40 bytes. Many mechanisms have been proposed for for extending the TCP option space, but the biggest challenge has been to get additional option space in the initial SYN packet. This memo presents a optional four-way TCP handshake to allow extended option space to be used in SYN packets in both directions. "Framework for Deriving Interface Data Schema from UML Information Models", Malcolm Betts, Nigel Davis, Hing-Kam Lam, Bernd Zeuner, Scott Mansfield, Paul Doolan, 2015-03-08, This draft describes a framework for how purpose and protocol specific interfaces can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in interface specification development is to promote convergence, interoperability, and efficiency. "Existing Support for Network Operations in Multilayer Transport Network based upon unified approach to OAM (Layer 0 - Layer 2)", Hing-Kam Lam, Eve Varma, Scott Mansfield, Yuji Tochio, Huub van Helvoort, Maarten Vissers, Paul Doolan, 2015-04-27, This draft summarizes the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both technology-specific and generic across these technologies, relevant to leveraging OAM to support fault management, performance monitoring, and configuration management. Knowledge from this domain may be leveraged for the benefit of developing generic layer independent management for other layers. "PCEP Extension for Transporting TE Data", Dhruv Dhody, Young Lee, Daniele Ceccarelli, 2015-03-04, In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with TED population capability. "Quality of Service Marking and Framework in Overlay Networks", Frank Xia, Behcet Sarikaya, Fan Shi, 2015-03-05, Overlay networks such as The Virtual eXtensible Local Area Network enable multiple tenants to operate in a data center. Each tenant needs to be assigned a priority group to prioritize their traffic using tenant based quality of service marking. Also, cloud carriers wish to use quality of service to differentiate different applications, i.e. legacy, traffic based marking. For these purposes, Quality of Service bits are assigned in the Virtual eXtensible Local Area Network outer Ethernet header. How these bits are assigned and are processed in the network are explained in detail. Also the document presents a quality of service framework for overlay networks such as Virtual eXtensible Local Area Network. "MPLS Flow Identification", Stewart Bryant, Carlos Pignataro, Mach Chen, Zhenbin Li, Greg Mirsky, 2015-03-26, 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. "Optimized Ingress Replication solution for EVPN", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, Aldrin Isaac, 2015-07-06, Network Virtualization Overlay (NVO) networks using EVPN as control plane may use ingress replication (IR) or PIM-based trees to convey the overlay multicast traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks. "AC-influenced Designated Forwarder Election for (PBB-)EVPN", Jorge Rabadan, Kiran Nagaraj, Senthil Sathappan, Vinod Prabhu, Wim Henderickx, 2015-07-04, The Designated Forwarder (DF) in (PBB-)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. "Certificate Transparency for Domain Name System Security Extensions", Dacheng Zhang, Daniel Kahn Gillmor, ana.hedanping@huawei.com, Behcet Sarikaya, Ning Kong, 2015-07-05, In draft-ietf-trans-rfc6962-bis, a solution (Certificate Transparency) is proposed for publicly logging the existence of Transport Layer Security (TLS) certificates using Merkle Hash Trees. This document proposes a mechanism to extend Certificate Transparency for DNSSEC which publicly logs the DS RRs to notice the issuance of suspect key signing keys. "IPFIX Information Elements for inspecting network security issues", Tianfu Fu, Dacheng Zhang, ana.hedanping@huawei.com, Liang Xia, 2015-04-28, IPFIX protocol has been used to carry Information Elements, which are defined to measure the traffic information and information related to the traffic observation point, traffic metering process and the exporting process. Network or device status are checked through analysing neccessary observed information. Although most of the existing Information Elements are useful for network security inspection, they are still not sufficient to determine the reasons behind observed events such as for DDOS attack, ICMP attack, and fragment attack. To allow administrators making effective and quick response to the attacks, this document extends the standard Information Elements and describes the formats for inspecting network security. "Segment Routing Prefix SID extensions for BGP", Keyur Patel, Stefano Previdi, Clarence Filsfils, Arjun Sreekantiah, Saikat Ray, Hannes Gredler, 2015-07-06, 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. "Architectural Considerations for Diameter Load Information", Ben Campbell, Steve Donovan, Jean-Jacques Trottin, 2015-03-09, RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. This document explores some architectural considerations for a mechanism to send Diameter load information. "BGP-Prefix Segment in large-scale data centers", Clarence Filsfils, Stefano Previdi, Jon Mitchell, Ebben Aries, Petr Lapukhov, Gaya, Dmitry Afanasiev, Tim Laberge, Edet Nkposong, Mohan Nanduri, Jim Uttaro, Saikat Ray, 2015-07-06, This document describes the motivation and benefits for applying segment routing in the data-center. It describes the design to deploy segment routing in the data-center, for both the MPLS and IPv6 dataplanes. "Multipath TCP timestamp option", Olivier Bonaventure, 2015-07-02, The TCP timestamps defined in [RFC1323] were designed to improve round-trip-time estimations and provide protection against wrapped sequence numbers (PAWS). This draft clarifies the utilisation of timestamps by Multipath TCP and proposes a new timestamp option that better suits the needs of Multipath TCP. "Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation", Marianne Mohali, 2015-05-11, [RFC4458] defines a "cause" URI parameter as having predefined values for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the Request-URI and in the History- Info header field defined in [RFC7044] in some specific retargeted requests defined in this document. This specification creates a new predefined value for cases when the retargeting is caused by a specific service action leading to a called service access number translation. This document updates [RFC4458]. "Egress Peer Engineering using BGP-LU", Hannes Gredler, Kaliraj Vairavakkalai, Chandra R, Balaji Rajagopalan, Luyuan Fang, Ebben Aries, 2015-03-09, The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links. "Using Autonomic Control Plane for Stable Connectivity of Network OAM", Toerless Eckert, Michael Behringer, 2015-03-06, 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. "A Lightweight TURN Architecture and Specification (TURN-Lite)", Aijun Wang, Bing Liu, 2015-07-01, This document proposes a new relay-based NAT traversal architecture called TURN-Lite which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] NAT devices. The key mechanism in TURN-Lite is the newly defined "Couple" operation (using STUN [RFC5389] message format) which allows the TURN-Lite servers to be easily incorporated into existing CGN devices/CDN nodes which are already deployed within the network in a distributed manner. "CT for Binary Codes", Dacheng Zhang, Daniel Kahn Gillmor, ana.hedanping@huawei.com, Behcet Sarikaya, 2015-07-05, This document proposes a solution to use Certificate Transparency for publishing software (or the digest of binary codes) and their signatures. "Mobile Throughput Guidance Inband Signaling Protocol", Ankur Jain, Andreas Terzis, Hannu Flinck, Nurit Sprecher, Swaminathan, Kevin Smith, 2015-03-09, The bandwidth available for end user devices in cellular networks can vary by an order of magnitude over a few seconds due to changes in the underlying radio channel conditions, as device mobility and changes in system load as other devices enter and leave the network. Furthermore, packets losses are not always signs of congestion. The Transmission Control Protocol (TCP) can have difficulties adapting to these rapidly varying conditions leading to inefficient use of a cellular network's resources and degraded application performance. Problem statement, requirements and the architecture for a solution is documented in [Req_Arch_MTG_Exposure] This document proposes a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. This "Throughput Guidance" (TG) information would indicate the throughput estimated to be available at the radio downlink interface (between the Radio Access Network (RAN) and the mobile device (UE)). TCP server can use this TG information to ensure high network utilization and high service delivery performance. The document describes the applicability of the proposed mechanism for video delivery over cellular networks; it also presents test results from live operator's environment. "Cryptographic protection of TCP Streams (tcpcrypt)", Andrea Bittau, Dan Boneh, Daniel Giffin, Mike Hamburg, Mark Handley, David Mazieres, Quinn Slack, 2015-07-02, This document presents tcpcrypt, a TCP extension for cryptographically protecting TCP connections. Tcpcrypt maintains the confidentiality of data transmitted in TCP connections against a passive eavesdropper. Additionally, applications that perform authentication can obtain end-to-end confidentiality and integrity guarantees by tying authentication to tcpcrypt Session ID values. The extension defines a new TCP option, CRYPT, which is designed to provide compatible interworking with TCPs that do not implement tcpcrypt. The CRYPT option allows hosts to negotiate the use of tcpcrypt and establish shared, secret encryption keys. These keys are then used with an authenticated-encryption mode to protect both the confidentiality and the integrity of transmitted application data. Tcpcrypt is designed to require relatively low overhead, particularly at servers, so as to be useful even in the case of servers accepting many TCP connections per second. "Autonomic Prefix Management in Large-scale Networks", Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong, 2015-05-04, This document describes an autonomic solution for prefix management in large-scale networks. "Fine-grained Support of Security Services for Constrained Devices using DTLS", Jaeduck Choi, Gunhee Lee, Namhi Kang, Seung Jung, Souhwan Jung, 2015-03-24, This document proposes a method that can selectively apply application data encryption to the DTLS record layer. The CoAP used for resource-constrained devices defines the use of DTLS as a basic security mechanism, and CoAP standard specifies the use of AES_CCM that provides data integrity and confidentiality as a cipher suite for DTLS. However, not all CoAP messages require both data integrity and confidentiality. For example, in case of CoAP messages that include information for turning a light off at home or in a building, or simple ACK information, encryption might not be necessary because such information might not be useful to attackers. Furthermore, from the perspective of effective resource use of resource-constrained devices, reducing the computation load required to perform data encryption every time is necessary. This document describes the methods for CoAP nodes to establish DTLS security channels using the AES_CCM cipher suite, and to selectively apply the encryption function in the DTLS record layer by considering sensitivity to application data leakage. "Integrated Security with Access Network Use Case", Ke Wang, Xiaojun Zhuang, 2015-03-09, In traditional telecommunication system, operators usually provide general and limited security protection service for users during access (e.g. AKA in 3G/4G network). Now, with the development of network virtualization technology and data center, physical network devices can be replaced by network function softwares which are running on virtual machines and the network function can be flexible and elastic. Operators can provide users with more security services. So this interfaces between operator's network and users are highly desired. These interfaces will be used to request/achieve (Virtual) Network Security Functions from operator's network. This draft describes use cases for using the interface in operator's network environment. "YANG Data Model for Active-Active NVEs Configuration", Mingui Zhang, Jinwei Xia, Fu Qiao, Muhammad Durrani, Zu Qiang, Sujay Gupta, 2015-03-09, When a Tenant System is not collocated with Network Virtualization Edges (NVEs), it's possible for this Tenant System to connect to a group of NVEs or a single NVE with multiple underlay IP addresses to use the active-active multihoming L2/L3 service provided by these NVEs. This document defines the YANG data model that can be used to configure NVEs of a NVO3 network to achieve active-active multi- homing. "Software-Defined Networking Based Security Services using Interface to Network Security Functions", Jaehoon Jeong, Hyoungshick Kim, Park Jung-Soo, 2015-07-06, This document describes a framework, use cases, and requirements for security services based on Software-Defined Networking (SDN) using a common interface to Network Security Functions (NSF). It specifies objectives and requirements in SDN-based security services using an interface to NSF (I2NSF). Also, it proposes two use cases, such as centralized firewall system and centralized DDoS-attack mitigation system. "A Layer Independent Operations, Administration, and Maintenance(OAM)Management YANG Data Model Extension for BFD Support", Zitao Wang, Liang Xia, Deepak Kumar, Qin Wu, 2015-03-06, This document presents a YANG Data model for BFD support. The YANG Model presented in this document extends the YANG model for Layer independent OAM Management with BFD technology specifics. "Analysis on Forwarding Methods for Service Chaining", Shunsuke Homma, Kengo, Diego Lopez, Martin Stiemerling, David Dolson, Alexey Gorbunov, Nicolai Leymann, 2015-07-03, This document presents the results of analyzing packet forwarding methods and path selection patterns for achieving Service Chaining. In Service Chaining, data packets need to be forwarded to the appropriate service functions deployed in networks based on service provided for the packets, and distribution of the service-oriented route information and steering data packets following the route information would be required. "Additional RPC definitions to Generic YANG Data Model for layer Independent OAM Management", Zitao Wang, Qin Wu, 2015-04-09, [I-D.tissa-lime-yang-oam-model] defines a Generic YANG data model for Layer independent OAM Management. This document proposes additional extension to this YANG model which is complementary to the one defined in the [I-D.tissa-lime-yang-oam-model].The extension include generic notification and generic rpc command for Unified Management Plane OAM to be used within IETF in a layer independent manner. The generic notification and rpc command described in this document can be applied to various network technologies and includes technology independent configuration data and state data. "Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network", Hao Weiguo, Lucy Yong, Susan Hares, Osama Zia, 2015-05-20, This draft describes inter-as option-C solution between NVO3 network and MPLS/IP VPN network. BGP label routing information is extended to create multi-hop forwarding path between local NVE and remote PE. Also to ensure VPNv4 route exchange correctly between local NVE and remote PE, VN ID space should be partitioned, only the VN IDs of lower 1 Million can be used for interconnection with outer MPLS VPN network using option-C solution, the rest 15 Million VN IDs can only be used for intra DC. "YANG Data Model for SFC Operations, Administration, and Maintenance (OAM)", Liang Xia, Qin Wu, Deepak Kumar, Mohamed Boucadair, Zitao Wang, 2015-05-03, This document defines YANG data model for Service Function Chaining (SFC Operations, Administration, and Maintenance (OAM). It extends from the basic YANG data model for Layer independent OAM Management defined in [I-D.tissa-lime-yang-oam-model] with SFC technology specifics. It includes SFC OAM related configuration, state, and RPC information data. "First-Party-Only Cookies", Mike West, 2015-05-13, This document updates RFC6265 by defining a "First-Party-Only" attribute which allows servers to assert that a cookie ought to be sent only in a "first-party" context. This assertion allows user agents to mitigate the risk of cross-origin information leakage, and provides some minimal protection against cross-site request forgery attacks. "Proposal for research on human rights protocol considerations", Avri Doria, Niels Oever, Joana Varon, 2015-03-09, Work has been done on privacy issues that should be considered when creating an Internet protocol. This draft suggests that similar considerations may apply for other human rights such as freedom of expression or freedom of association. A proposal is made for work in the IRTF researching the possible connections between human rights and Internet standards and protocols. The goal is to create an informational RFC concerning human rights protocol considerations. Discussion on this draft at: hrpc@article19.io "Authorization server identity", Christer Holmberg, 2015-05-28, The 3rd-Generation Partnership Project (3GPP) has defined how the WebRTC framework can be used to provide access to IMS services. Users can use "web credentials" (e.g. a username and password) to obtain an authorization token (e.g. an OAuth 2.0 access token), which is included in the user registration request sent towards the IMS network. 3GPP has specified a requirement, that the eP-CSCF shall be able to include a string value, representing the identity of the WAF, in the REGISTER request forwarded towards the S-CSCF. The S-CSCF can use the identity for e.g. policy decisions. This document defines a new Authorization header field parameter, 'authorization-entity', which the eP-CSCF can include in a REGISTER request in order to convey the identity of the WAF towards the S-CSCF. "Multi-Layering OAM for Service function Chaining", Chunming Wu, Cui Wang, Wei Meng, Bhumip Khasnabish, 2015-06-15, This document tries to discuss some problems in SFC OAM framework document and proposes the SFC OAM multi-layering requirements in SFC domain to improve the troubleshooting efficiency. "Framework for Point-to-Multipoint MPLS-TP OAM", Kaoru Arai, Hiroki Date, Makoto Murakami, Weiqiang Cheng, 2015-03-31, The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport. This document discusses and specifies the P2MP framework primarily related to OAM and related management in MPLS-TP networks. This document mainly refers to RFC5654 and RFC6371. The main focus is on the details that are not covered or not clarified in relevant RFCs such as RFC5654, RFC5860, RFC5921, RFC5951, RFC6371, and RFC7167. Note: This I-D was made and updated including the discussions in ITU-T SG15, which were described in Liaison Statements such as (https://datatracker.ietf.org/liaison/1235/) This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Benchmarking Methodology for Virtualization Network Performance", Lu Huang, Gu Rong, Bob Mandeville, Brooks Hickman, 2015-04-28, As the virtual network has been widely established in IDC, the performance of virtual network has become a valuable consideration to the IDC managers. This draft introduces a benchmarking methodology for virtualization network performance based on virtual switch. "Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Bundling Registration", Ning Kong, Jiankang Yao, XiaoDong Lee, Jiagui Xie, Wil Tan, 2015-04-13, This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. "A survey of issues related to IPv6 Duplicate Address Detection", Andrew Yourtchenko, Erik Nordmark, 2015-03-03, This document enumerates the practical issues observed with respect to Duplicate Address Detection. "Safe increase of the TCP's Initial Window Using Initial Spreading", Renaud Sallantin, Fabrice Arnal, Emmanuel Dubois, Emmanuel Chaput, Andre-Luc Beylot, 2015-04-23, This document proposes a new fast start-up mechanism to improve the short-lived TCP connections performance. Initial Spreading allows to safely increase the Initial Window size in any cases, and notably in congested networks. Merging the increase in the IW with the spacing of the segments belonging to the Initial Window (IW), Initial Spreading is a very simple mechanism that improves short-lived TCP flows performance and does not deteriorate long-lived TCP flows performance. "Generic UDP Encapsulation (GUE) for Network Virtualization Overlay", Lucy Yong, Tom Herbert, Osama Zia, 2015-06-15, This document describes network virtualization overlay encapsulation scheme by use of Generic UDP Encapsulation (GUE) [GUE]. It allocates one GUE optional flag and defines a 32 bit field for Virtual Network Identifier (VNID). "Generic UDP Encapsulation (GUE) for Secure Transport", Lucy Yong, Tom Herbert, 2015-05-21, This document specifies the ability of Generic UDP Encapsulation (GUE) [GUE] to provide secure transport over IP networks and the Internet, including GUE header integrity protection and origin authentication and GUE payload encryption. These are optional features of GUE. "Tenant Traffic Handling in NVO3", Zu Qiang, 2015-06-18, This draft discusses the considerations on how to handle the tenant traffic in NVO3 architecture and several related issues which need to be considered when designing a NVO3 based virtualized data center network for multiple tenants. "Concise Binary Object Representation (CBOR) Tags for ASN.1 Object Identifiers", Carsten Bormann, Sean Leonard, 2015-07-06, The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define CBOR tags <> and <> [values TBD] for ASN.1 object identifiers. It is intended as the reference document for the IANA registration of the CBOR tags so defined. "Elasticity VNF", Zu Qiang, Robert Szabo, 2015-03-03, This draft is an analysis of Network Function Virtualization (NFV) applications based on the NFV architecture, use cases and requirements. The purpose of this analysis is to identify any NFV characteristics related issues. The analysis is focusing on elastic VNF with predicable performance, reliability and security. Only the issues which are unique to NFV are discussed in this document. "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler, 2015-07-06, 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. "DevOps for Software-Defined Telecom Infrastructures", Catalin Meirosu, Antonio Manzalini, Juhoon Kim, Rebecca Steinert, Sachin Sharma, Guido Marchetto, Ioanna Papafili, Kostas Pentikousis, Steven Wright, 2015-07-06, Carrier-grade network management was optimized for environments built with monolithic physical nodes and involves significant deployment, integration and maintenance efforts from network service providers. The introduction of virtualization technologies, from the physical layer all the way up to the application layer, however, invalidates several well-established assumptions in this domain. This draft opens the discussion in NFVRG about challenges related to transforming the telecom network infrastructure into an agile, model-driven production environment for communication services. We take inspiration from data center DevOps regarding how to simplify and automate management processes for a telecom service provider software-defined infrastructure (SDI). Finally, we introduce challenges associated with operationalizing DevOps principles at scale in software-defined telecom networks in three areas related to key monitoring, verification and troubleshooting processes. "Modeling Video Traffic Sources for RMCAT Evaluations", Xiaoqing Zhu, Sergio de la Cruz, Zaheduzzaman Sarker, 2015-07-06, This document describes two reference video traffic source models for evaluating RMCAT candidate algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on target video rate. The second model is trace- driven, and emulates the encoder output by scaling the pre-encoded video frame sizes from a widely used video test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a video traffic source and the congestion control module. "Framework for Service Function Path Control", Linda Dunbar, Andrew Malis, 2015-03-06, This draft describes the framework of Service Function Path Control when some service functions on the path fail or need to be replaced. "A YANG Data Model for Base ALTO Data", Xiao Shi, Y. Yang, Michael Scharf, 2015-03-22, This document defines a YANG model for the base ALTO information resources defined in [RFC7285]. In particular, the introduction of this model allows a standard approach to provision and update ALTO state stored at an ALTO server. "Analysis of Existing Work for I2NSF", Susan Hares, Dacheng Zhang, Robert Moskowitz, Hosnieh Rafiee, 2015-07-06, This document analyzes the status of the arts in industries and the existing IETF work/protocols that are relevant to I2NSF. 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. "June 29, 2015", Goran Selander, John Mattsson, Francesca Palombini, Ludwig Seitz, 2015-06-29, This memo presents OSCOAP, a scheme for protection of request and response messages of the Constrained Application Protocol (CoAP), using data object security. "LFA selection for Multi-Homed Prefixes", P. Sarkar, Hannes Gredler, Shraddha Hegde, Chris Bowers, Bruno Decraene, 2015-02-20, This document shares experience gained from implementing algorithms to determine Loop-Free Alternates for multi-homed prefixes. In particular, this document provides explicit inequalities that can be used to evaluate neighbors as a potential alternates for multi-homed prefixes. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. "Multihoming support for Residential Gateways", Pierrick Seite, Alper Yegin, Sri Gundavelli, 2015-06-25, The Quality-of-Experience of a fixed-network user can be significantly improved by enabling the Residential Gateway (RG) providing IP connectivity services to connect to the internet through multiple access networks (Example: LTE and DSL) and use all the available network bandwidth for the user traffic. This approach enables a service provider to leverage all the availble access networks and to offer guaranteed Quality-of-Service to the end-user on any application basis. Furthermore, the mobility functions in the residential gateway and in the service provider network will be able to monitor the performance of all the access paths and dynamically change the routing path for an application. This document investigates the use of IP mobility protocols for supporting this use-case and it also identifies the needed protocol extensions. "HTTP State Management Mechanisms with Multiple Addresses User Agents", Eric Vyncke, 2015-03-05, HTTP servers usually save session states in their persistent storage indexed by session cookies generated by the HTTP servers. It is up to the HTTP user-agent to send this session cookie on each HTTP request. Some HTTP servers check whether the cookie is associated with the HTTP user-agent by the means of the user-agent IP address. Everything linking a state to an IP address (such as OAuth access code) to an IP address has the same issue. If the Happy Eyeball mechanism is used to select between IPv6 and IPv4, it may happen that while using the same HTTP server, some HTTP requests are done over IPv6 and the others over IPv4, which leads to two different sets of session states in the HTTP server. This has the consequence of inconsistencies at the HTTP server. The only purpose of this document is to document this issue in more details than in section 8.2 of RFC 6883 including security considerations and mitigations. A similar problem arises with the use of non RFC 6888 compliant Carrier-Grade NAT (CGN) devices used to access an IPv4-only HTTP server or HTTP user-agent using multi-homing. "A Survey of Worldwide Censorship Techniques", Joe Hall, Michael Aaron, Ben Jones, 2015-04-28, This document describes the technical mechanisms used by censorship regimes around the world to block or degrade internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties being exploited and mechanisms used to censor end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended to be a reference. "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2015-07-06, The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. "EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Tapraj Singh, 2015-07-06, EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced capabilities among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and the set of PE devices that they are connected to. Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to- Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. "Requirements for Private Media in a Switched Conferencing Environment", Paul Jones, Nermeen Ismail, David Benham, Nathan Buckles, John Mattsson, Yi Cheng, Richard Barnes, 2015-03-06, This document specifies the requirements for ensuring the privacy and integrity of real-time media flows between two or more endpoints communicating in a switched conferencing environment. This document also provides a high-level overview of switched conferencing in order to establish a common understanding of the goals and objectives of this work. "Tetrys, an On-the-Fly Network Coding protocol", jonathan.detchart@isae.fr, Emmanuel Lochin, Jerome Lacan, Vincent Roca, 2015-07-06, This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay and loss sensitive data over a lossy network. Tetrys can recover from erasures within a RTT- independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications. "MPLS-Based Hierarchical SDN for Hyper-Scale DC/Cloud", Luyuan Fang, Deepak Bansal, Fabio Chiussi, Chandra R, Ebben Aries, Shahram Davari, Barak Gafni, daniel.voyer@bell.ca, 2015-07-06, This document describes Hierarchical SDN (HSDN), an architectural solution to scale the Data Center (DC) and Data Center Interconnect (DCI) networks to support tens of millions of physical underlay endpoints, while efficiently handling both Equal Cost Multi Path (ECMP) load-balanced traffic and any-to-any end-to-end Traffic Engineered (TE) traffic. HSDN achieves massive scale using surprisingly small forwarding tables in the network nodes. HSDN introduces a new paradigm for both forwarding and control planes, in that all paths in the network are pre-established in the forwarding tables and the labels can identify entire paths rather than simply destinations. The HSDN forwarding architecture is based on four main concepts: 1. Dividing the DC and DCI in a hierarchically-partitioned structure; 2. Assigning groups of Underlay Border Nodes in charge of forwarding within each partition; 3. Constructing HSDN MPLS label stacks to identify endpoints and paths according to the HSDN structure; and 4. Forwarding using the HSDN MPLS labels. "Gossiping in CT", Linus Nordberg, Daniel Kahn Gillmor, Tom Ritter, 2015-07-06, This document describes three gossiping mechanisms for Certificate Transparency (CT) [RFC6962]: SCT Feedback, STH Pollination and Trusted Auditor Relationship. SCT Feedback enables HTTPS clients to share Signed Certificate Timestamps (SCTs) (Section 3.2 of [RFC6962]) with CT auditors in a privacy-preserving manner by sending SCTs to originating HTTPS servers which in turn share them with CT auditors. In STH Pollination, HTTPS clients use HTTPS servers as pools sharing Signed Tree Heads (STHs) (Section 3.5 of [RFC6962]) with other connecting clients in the hope that STHs will find their way to auditors and monitors. HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs with trusted auditors or monitors directly, with expectations of privacy sensitive data being handled according to whatever privacy policy is agreed on between client and trusted party. "Virtual Topologies for Service Chaining in BGP/IP MPLS VPNs", Rex Fernando, Dhananjaya Rao, Luyuan Fang, Maria Napierala, Ning So, Adrian Farrel, 2015-04-26, This document presents techniques built upon BGP/IP MPLS VPN control plane mechanisms to construct virtual topologies for service chaining. These virtual service topologies interconnect network zones and constrain the flow of traffic between these zones via a sequence of service nodes so that service functions can be applied to the traffic. This document also describes approaches enabled by both the routing control plane and by network orchestration to realize these virtual service topologies. "Enhanced Mobility Anchoring in Distributed Mobility Management", Young-Han Kim, Seil Jeon, 2015-07-06, This document presents a new perspective for the solution design of enhanced mobility anchoring over DMM deployment models described in [draft-sijeon-dmm-deployment-models]. "Router Buffer Sizes In The WAN", Kamala Subramaniam, Darren Loher, 2015-07-09, This draft identifies the set of data that needs to be collected, and analyzed to quantify router buffer sizes used in routers in the Wide Area Network (WAN). The scope of this draft is limited to WAN links that have link latencies of 40 to 150 milliseconds. Reducing router buffer sizes has many advantages, the most important being cost. However, there is not much data available today to effectively calculate this. This draft details use cases for the study, and lists data that needs to be taken into consideration to be able to quantify the size of router buffers. The details of the individual measurement metrics are beyond the scope of this document. Neither does the draft identify methods to gather the data. What it identifies is a need to be able to collect, and report this empirical data in a readable fashion thus providing the ability to study and compare data in a more standardized method. "Bootstrapping Key Infrastructures", Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, 2015-07-06, This document specifies automated bootstrapping of an key infrastructure using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based service on the Internet. Before being authenticated, a new device has only link-local connectivity, and does not require a routable address. When a vendor provides an Internet based service, devices can be forced to join only specific domains but for constrained environments we describe a variety of options that allow bootstrapping to proceed. "The Archive Top-Level Media Type for File Archives", Sean Leonard, Matthew Kerwin, 2015-05-05, This document defines a new top-level media type to be known as "archive", which defines a fundamental type of media with unique presentational, hardware, and processing aspects. "Cooperative Stateful Path Computation Element (PCE) for Inter-Domain Inter-Vendor PCE-initiated LSP Setup", Xiaoping Zheng, Nan Hua, Wangyang Liu, Yinqiu Jia, Bingkun Zhou, Guoying Zhang, 2015-04-27, A stateful Path Computation Element (PCE) maintains the information of Label Switched Path (LSP) and resource availability within a domain. Multiple stateful PCEs are able to provide traffic engineering inter-domain LSPs through cooperating with each other. This document introduces the applicability of cooperative stateful PCE for establishing inter-domain inter-vendor LSPs which are initiated by PCE. "Multiple Language Content Type", Nik Tomkinson, Nathaniel Borenstein, 2015-07-06, This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language code and selected by the email client based on a user's language settings or locale. "A Solution Framework for Private Media in a Switched Conferencing", Paul Jones, Nermeen Ismail, David Benham, 2015-03-06, This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where the switching conference server is not entrusted with the media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). "YANG data model for Flexi-Grid Optical Networks", Universidad de Madrid, Victor Lopezalvarez, Oscar Gonzalez de Dios, Daniel King, Young Lee, Zafar Ali, 2015-07-06, This document defines a YANG model for managing flexi-grid DWDM Networks. The model described in this document is composed of two submodels: one to define an flex-grid traffic engineering database, and other one to describe the flex-grid paths or media channels. "Media Types for Sensor Markup Language (SENML)", Cullen Jennings, Zach Shelby, Jari Arkko, Ari Keranen, 2015-07-06, 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. "Stateless Client Identifier for OAuth 2", J. Bradley, Justin Richer, 2015-05-21, This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. "NSH Context Header Allocation -- Mobility", Jeffrey Napper, Surendra, 2015-05-16, This document provides a recommended allocation of the mandatory fixed context headers for a Network Service Header (NSH) within the mobility service provider network context. NSH is described in detail in [ietf-sfc-nsh]. This allocation is intended to support uses cases as defined in [ietf-sfc-use-case-mobility]. "PSTNization of the Internet", Radi Romansky, Bhumip Khasnabish, 2015-06-28, This draft discusses the features and functions that the Internet must support in order to be as robust and trustworthy as the public switched telephone network (PSTN, http://en.wikipedia.org/wiki/ Public_switched_telephone_network). In general the PSTN-like features and functions include verifiable addressing and numbering, higher privacy and security, increased reliability (no more than around five minutes of unplanned outage over one year time period), survivability and resiliency, desirable level of scalability, alarms, correlation, and diagnosis capability, and local/international level of accountability. Incorporation of these (or similar) features are expected to harden the Internet. The topics related to Internet hardening were discussed during IETF88 technical plenary (http://www.ietf.org/proceedings/88/technical- plenary.html) in Vancouver, BC, Canada in Nov. 2013. A follow-up joint W3C/IAB workshop on strengthening the Internet against pervasive monitoring (STRINT, https://www.w3.org/2014/strint) was held before IETF89 meeting in London, UK. During the IETF90 Technical Plenary Session (http://www.ietf.org/proceedings/90/minutes/minutes-90-iab- techplenary) on Monday, 21 July 2014 in Toronto, Canada the Technical Topic discussion focused on Network topology and geography. The presentations revealed that for business relationship and/or policy reasons, local traffic routinely cross national borders for so called 'efficient' routing, thereby facilitating monitoring, copying, and surveillance of traffic from users' sessions by both authorized and unauthorized entities. All of the technical presentations are available at the website of IETF90 proceedings(http://www.ietf.org/proceedings/90/slides/slides-90-iab- techplenary-9.pdf). In this draft, we discuss the requirements for PSTNization of Internet interfaces, protocols, services, and management and configuration capabilities. NOTE: We are looking for additional contributors to update the contents of Section 2 to Section 6. If you are interested, please send an email to draft-rdsx1-intarea-pstnize-internet@tools.ietf.org with the relevant Section Number and Section Title in the Subject line of your email with an estimated completion time. "Automatic discovery of RFC 5626 Edge Proxies using U-NAPTR", Michael Procter, oej, 2015-05-18, [RFC5626] (commonly known as 'SIP outbound') defines mechanisms that permit SIP (Session Initiation Protocol) UAs (User Agents) to maintain multiple connections to a registrar or proxy via multiple Edge Proxies, known as the outbound-proxy-set. Discovering the URIs that make up the outbound-proxy-set is left to configuration or future discovery mechanisms. This draft defines a simple discovery mechanism based on U-NAPTR [RFC4848] that enables UAs to discover the URIs of all the Edge Proxies in the outbound-proxy-set without requiring additional configuration on the UA. "Audit in OAuth 2.0", Zhanna Tsitkov, 2015-01-23, This specification is an effort to provide guidelines for implementing the Audit functionality for OAuth 2.0 enabled environments. The data of interest for the OAuth 2.0 audit includes scopes, permissions, policies and other authorization and authentication related information. It can be used by resource and authorization servers for detecting security-related problems in real time and fast violation response, or by government agencies and various institutions for after-the-fact forensic and compliance analysis. "Key Management Service Architecture", Andrew Biggs, Shaun Cooley, 2015-07-03, In the interest of addressing pervasive threats to the confidentiality and integrity of online communications identified by the Internet community [I-D.barnes-pervasive-problem] this specification introduces an open architecture for the establishment, management, and secure distribution of cryptographic keys for use in the end-to-end (E2E) encryption of online communications and shared content. This architecture allows for the independent deployment of dedicated key management services in a manner that supports the adoption of third-party communications and data sharing services by individuals and organizations that require full and exclusive discretion over the confidentiality of their data. "New Media Control Protocol Above TCP in Transmission Layer", Fei Wang, Zesong Fei, 2015-05-20, This document describes a new Media Control Protocol (MCP) above the TCP layer in multimedia transimission network. The MCP have the label to show the classification of the data from the appliation layer.It also can identify and label the transimission in wired or wireless mode. These tags can optimize the TCP transimission with different methods. "The IMAP APPENDLIMIT Extension", Narendra Bisht, 2015-02-27, This memo defines an extension to the IMAP service whereby a server can advertise its capability, to support maximum mail upload size using CAPABILITY, SELECT/EXAMINE and LIST command. "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz Chroboczek, 2015-05-27, This document describes extensions to the Babel routing protocol to support source-specific routing. "Policy Architecture and Framework for NFV Infrastructures", Norival Figueira, Ram (Ramki) Krishnan, Diego Lopez, Steven Wright, 2015-06-17, A policy architecture and framework is discussed to support NFV environments, where policies are used to enforce business rules and to specify resource constraints in a number of subsystems. This document approaches the policy framework and architecture from the perspective of overall orchestration requirements for services involving multiple subsystems. The framework extends beyond common orchestration constraints across compute, network, and storage subsystems to include energy conservation. This document also analyses policy scope, global versus local policies, policy actions and translations, policy conflict detection and resolution, interactions among policies engines, and a hierarchical policy architecture/framework to address the demanding and growing requirements of NFV environments, that could also be applicable to cloud infrastructures in general. "A Routing Header Dispatch for 6LoWPAN", Pascal Thubert, Carsten Bormann, Laurent Toutain, Robert Cragie, 2015-07-02, This specification provides a new 6LoWPAN dispatch type for use in Route-over and mixed Mesh-under and Route-over topologies, that reuses the encoding of the mesh type defined in RFC 4944 for pure Mesh-under topologies. This specification also defines a method to compress RPL Option (RFC6553) information and Routing Header type 3 (RFC6554), an efficient IP-in-IP technique and opens the way for further routing techniques. This extends 6LoWPAN Transmission of IPv6 Packets (RFC4944), and is applicable to new link-layer types where 6LoWPAN is being defined. "Key Chain YANG Data Model", Acee Lindem, Yingzhen Qu, Derek Yeung, Helen Chen, Jeffrey Zhang, Yi Yang, 2015-07-03, This document describes the key chain YANG data model. A key chain is a list of elements each containing a key, send lifetime, accept lifetime, and algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, keys and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. Key chains are commonly used for routing protocol authentication and other applications. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key. "Service Function Chaining OAM in MPLS-SPRING Networks", Jianjie You, Xiaohu Xu, 2015-01-11, To perform Service Function Chaining (SFC) in networks where both MPLS and SPRING (Source Packet Routing in Networking) are enabled, it is required to be able to detect Service Function (SF) connectivity and availability. This document proposes a simple mechanism for SF connectivity and availability detection by using the MPLS echo request and reply messages as defined in [RFC4379]. "A YANG Data Model for Virtual Router Redundancy Protocol (VRRP)", Xufeng Liu, Athanasios Kyparlis, Ravi Parikh, Acee Lindem, Mingui Zhang, 2015-03-24, This document describes a data model for Virtual Router Redundancy Protocol (VRRP). Both version 2 and version 3 of VRRP are covered. "Simplemux. A generic multiplexing protocol", Jose Saldana, 2015-01-26, There are some situations in which multiplexing a number of small packets into a bigger one is desirable. For example, a number of small packets can be sent together between a pair of machines if they share a common network path. Thus, the traffic profile can be shifted from small to larger packets, reducing the network overhead and the number of packets per second to be managed by intermediate routers. This document describes Simplemux, a protocol able to encapsulate a number of packets belonging to different protocols into a single packet. It includes the "Protocol" field on each multiplexing header, thus allowing the inclusion of a number of packets belonging to different protocols on a packet of another protocol. The size of the multiplexing headers is kept very low (it may be a single byte when multiplexing small packets) in order to reduce the overhead. "Diet-ESP Context IKEv2 Extension", Daniel Migault, 2015-02-16, Diet-ESP has been designed for IoT to limit the IPsec ESP overhead in each IPsec packet. Diet-ESP is based on the standard IPsec ESP, and needs that peers agree on a Diet-ESP Context that defines how standard ESP packets can be compressed before being sent over the wire. Standard IPsec ESP can be agreed between peers using IKEv2. However, current IKEv2 does not make possible to negotiate a Diet-ESP Context, and thus to negotiate a Diet-ESP communication. This draft defines an extension for IKEv2 so peers can agree the Diet-ESP Context, and thus negotiate a Diet-ESP association. "Implicit IV for AES-CBC, AES-CTR, AES-CCM and AES-GCM", Daniel Migault, Tobias Guggemos, 2015-02-16, IPsec ESP with AES-CBC, AES-CTR, AES-CCM or AES-GCM sends an IV in each IP packet, which represents 8 or 16 additional bytes. In some context, such as IoT, the cost of sending bytes over computing these bytes is generally in favor of the computation. As a result, it would be better to compute the IV on each party then to send it. The document describes how to the IV can be generated instead of being sent. This document limits the IV generation for AES-CBC, AES- CTR, AES-CCM and AES-GCM but can be used for additional cryptographic mode and suites. "WebDAV: User Notifications", evert, Cyrus Daboo, 2015-06-09, This specification defines an extension to WebDAV that allows the server to provide notifications to users. "DHCPv6 Solution for Source Address Dependent Routing", Behcet Sarikaya, 2015-05-08, This document describes DHCPv6 solution for provisioning DHCPv6 client nodes for the next hop, IPv6 route prefixes and source address/prefixes the next hop supports. Using these options, an operator can configure multi-homed nodes where other means of source address dependent route configuration may be impractical. "Syntactic and Semantic Checks for Domain Validation Certificates", Stephen Kent, Rick Andrews, 2015-06-17, Certificate Transparency (CT) [RFC6962-bis] is a system for publicly logging the existence of X.509 certificates as they are issued or observed. The logging mechanism allows anyone to audit certification authority (CA) activity and detect the issuance of "suspect" certificates. Detecting mis-issuance of certificates is a primary goal of CT. A certificate is considered to be mis-issued if it fails to meet syntactic and/or semantic criteria associated with the type of certificate being issued. Mis-issuance can be detected by CT log servers, whose feedback to a CA could prompt the CA to not issue a suspect certificate. (Preventing the mis-issuance of such a certificate is preferable to issuing it and detecting it later.) Compliant CT log servers could offer these checks to a CA submitting a pre-certificate to be logged. These checks are intended to be used in an environment in which CAs optionally assert the version of the EV guidelines to which the submitted pre-certificate purportedly conforms. Log servers would then perform the checks of supported [CABF-DV] versions and include the CA's assertion and the log server's result in its Signed Certificate Timestamp (SCT). Monitors can also perform checks to detect suspect certificates on behalf of certificate Subjects. Checks performed by a Monitor also serve to double check log servers that claim to have checked a certificate, to identify those that are not doing the checks properly, e.g., because of errors, compromise, or conspiracy. This provides Monitors and CT clients with additional information when choosing which logs to use. "Syntactic and Semantic Checks for Extended Validation Certificates", Stephen Kent, Rick Andrews, 2015-06-17, Certificate Transparency (CT) [RFC6962-bis] is a system for publicly logging the existence of X.509 certificates as they are issued or observed. The logging mechanism allows anyone to audit certification authority (CA) activity and detect the issuance of "suspect" certificates. Detecting mis-issuance of certificates is a primary goal of CT. A certificate is considered to be mis-issued if it fails to meet syntactic and/or semantic criteria associated with the type of certificate being issued. Mis-issuance can be detected by CT log servers, whose feedback to a CA could prompt the CA to not issue a suspect certificate. (Preventing the mis-issuance of such a certificate is preferable to issuing it and detecting it later.) Compliant CT log servers could offer these checks to a CA submitting a pre-certificate to be logged. These checks are intended to be used in an environment in which CAs optionally assert the version of the EV guidelines to which the submitted pre-certificate purportedly conforms. Log servers would then perform the checks of supported [CABF-EV] versions and include the CA's assertion and the log server's result in its Signed Certificate Timestamp (SCT). Monitors can also perform checks to detect suspect certificates on behalf of certificate Subjects. Checks performed by a Monitor also serve to double check log servers that claim to have checked a certificate, to identify those that are not doing the checks properly, e.g., because of errors, compromise, or conspiracy. This provides Monitors and CT clients with additional information when choosing which logs to use. "URL Problem Statement and Directions", Sam Ruby, Larry Masinter, 2015-01-11, This document lays out the problem space of possibly conflicting standards between multiple organizations for URLs and things like them, and proposes some actions to resolve the conflicts. From a user or developer point of view, it makes no sense for there to be a proliferation of definitions of URL nor for there to be a proliferation of incompatible implementations. This shouldn't be a competitive feature. Therefore there is a need for the organizations involved to update and reconcile the various Internet Drafts, Recommendations, and Standards in this area. "Yang Data Model for BGP/MPLS IP VPNs", Shunwan Zhuang, Zhenbin Li, Xufeng Liu, Vic Liu, 2015-07-06, This document defines a YANG data model that can be used to configure and manage L3VPN (BGP/MPLS IP VPN). "Discovery of path characteristics using STUN", Tirumaleswar Reddy, Dan Wing, Paal-Erik Martinsen, Varun Singh, 2015-01-20, A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. "Conveying Event Tag with the Session Initiation Protocol REFER Method", Abhishek Gupta, 2015-06-22, This document extends the REFER method, defined in RFC 3515, to convey feature parameters defined in RFC 3840. "RSVP-TE Extensions for Abstract Error Report in Multi-Layer Traffic Engineered Networks", Jie Dong, Xiugang Wei, Victor Lopezalvarez, Oscar Gonzalez de Dios, 2015-07-04, This document provides extensions to the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support the report of abstract error information across the multi-layer network boundary using Generalized Multiprotocol Label Switching (GMPLS) User Network Interface (UNI). Such abstract error information is useful for efficient protection and restoration coordination of multi-layer Label Switched Paths (LSPs), and is helpful to the fault localization and diagnostics in the multi-layer networks. "Multiple multicast addressing architecture", Robert Chodorek, 2015-07-02, This document introduces a new class of IPv6 multicast addresses called "multiple multicast". We define multiple multicast as a set of multicast addresses belonging to one multicast session. "Task Extensions to iCalendar", Adrian Apthorp, Cyrus Daboo, Mike Douglass, 2015-01-04, This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) to provide improved status tracking, scheduling and specification of tasks. "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2015-07-06, This document describes a Session Traversal Utilities for NAT (STUN) usage for Path MTU Discovery (PMTUD) between a client and a server. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 2015-01-06, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", Murray Kucherawy, 2015-02-18, The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it has evolved since the publication of [RFC7437]. "DBOUND: DNS Administrative Boundaries Problem Statement", Andrew Sullivan, Jeff Hodges, John Levine, 2015-07-06, Some Internet client entities on the Internet make inferences about the administrative relationships among services on the Internet based on the domain names at which they are offered. At present, it is not possible to ascertain organizational administrative boundaries in the DNS, therefore such inferences can be erroneous in various ways. Mitigation strategies deployed so far will not scale. This memo outlines what issues are to be addressed. "Requirements for Diet-ESP the IPsec/ESP protocol for IoT", Daniel Migault, Tobias Guggemos, 2015-02-16, IPsec/ESP is used to secure end-to-end communications. This document lists the requirements Diet-ESP should meet to design IPsec/ESP for IoT. "Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite", Daniel Migault, Tobias Guggemos, 2015-02-16, ESP is a IPsec protocol that takes as input a Clear Text Data and outputs an encrypted ESP packet according to IPsec rules and parameters stored in different IPsec databases. Diet-ESP compresses the ESP fields. However, Diet-ESP does not consider compression of the Clear Text Data. Instead, if compression of the Clear Text Data is expected protocols like ROHCoverIPsec can be used. ROHCoverIPsec remains complex to implement in IoT devices, as states, and negotiations are involved between the compressors and decompressors of the two IoT devices. Most of this complexity can be avoided by considering the parameters that have been negotiated by IPsec. This document describes an extension of the Diet-ESP Context that enables the compression of the Clear Text Data, without implementing the complex ROHCoverIPsec framework. As opposed to ROHCoverIPsec the compression is not generic and as such all communication will not benefit from this compression. However, we believe this extension addresses most of IoT communications. "Diet-ESP: a flexible and compressed format for IPsec/ESP", Daniel Migault, Tobias Guggemos, 2015-02-16, IPsec/ESP secure every single IP packets exchanged between two nodes. This makes security transparent to the applications, as opposed to TLS or DTLS for example. IPsec/ESP has not widely been used to secure application because IPsec is implemented in the kernel space, and IPsec/ESP security rules are defined on the device -- similarly to firewall. In addition, IPsec/ESP introduces network overhead on an IP packet basis, as opposed as TLS/DTLS that introduces network overhead on an UDP or TCP segment basis. This mostly impacts devices that do not perform IP fragmentation. Such drawbacks are not anymore valid for IoT, and the IPsec/ESP may even better fits IoT usage and security requirements. IoT device are usually hardware dedicated for a given task or a given application which makes Kernel / user land split less significant. IoT devices send data that is most likely expected to fit in a single IP packet. Eventually, configuring IPsec/ESP security rules provides the ability to enforce the security of the device, as security is not handled on a per-application basis. Then the database structure of the IPsec/ ESP security policies perfectly match sleeping nodes. This document defines Diet-ESP that adapts IPsec/ESP for IoT. The goal of Diet-ESP is to reduce the size of the IPsec/ESP packet sent on the wire. As a result Diet-ESP is expected to compress traditional IPsec/ESP packet without impacting the security provided by IPsec/ESP. "NDN Message Format Proposal", Mark Stapp, 2015-01-08, This memo defines an on-the-wire format for Named-data Networking (NDN) protocol messages. NDN packets begin with a fixed-size header. After the header, the remainder of the message is composed of type- length-value (TLV) tuples. The Type and Length fields use a compact, fixed-size encoding scheme. The TLVs for message attributes that are standardized are defined in a registry. Part of the TLV number-space is reserved for standardized attributes. Other parts of the number- space are set aside for experimental use. "NDN Message Format Comparison", Mark Stapp, 2015-01-08, Several on-the-wire formats have been proposed for Named-data Networking (NDN) protocol messages. This memo compares the properties of four of these proposals, attempting to provide a framework for discussion and eventual consensus. "Home Network Prefix Renumbering in PMIPv6", Zhiwei Yan, Jong-Hyouk Lee, XiaoDong Lee, 2015-07-14, In the basic Proxy Mobile IPv6 (PMIPv6) specification, an Mobile Node (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its initial attachment for the Home Address (HoA) configuration. During the movement of the MN, this prefix remains unchanged and in this way it is unnecessary for the MN to reconfigure its HoA and reconnect the ongoing communications. However, the current protocol [RFC5213] does not specify related operations to support the MN to timely receive and use a new HNP when the allocated HNP changes. In this draft, a possible solution to support the HNP renumbering is proposed, as an update of RFC5213. "6TiSCH Security Architectural Considerations", Rene Struik, 2015-01-09, This document describes 6TiSCH security architectural elements with high level requirements and the security framework that are relevant for the design of the 6TiSCH security solution. "CCNx Semantics", marc.mosko@parc.com, 2015-03-09, This document describes the core concepts of the CCNx architecture and presents a minimum network protocol based on two messages: Interest and Content Object. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a Control message called an InterestReturn, whereby one system can return an Interest message to the previous hop due to an error condition. It indicates to the previous hop that the current system will not respond to the Interest. "CCNx Messages in TLV Format", marc.mosko@parc.com, 2015-03-09, 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. "Labeled Content Information", marc.mosko@parc.com, 2015-06-30, This document defines an RFC3986 URI compliant identifier called a Labeled Segment URI in which name segments carry a label. This allows differentiation between unrelated resources with similar identifiers. A URI scheme that specifies the use of labeled segment URIs conforms to the encoding rules presented here. This document also describes Labeled Content Information - a labeled segment URI (LS-URI) representation of network data. This scheme, called "lci:", is applicable to network protocols such as Content Centric networks (CCN). Labeled Content Information applies specific labels to each name segment of a URI to disambiguate between resources with similar names. This document defines a specific set of segment labels with label semantics. "CCNx Content Object Chunking", marc.mosko@parc.com, 2015-07-01, This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. This includes specification for the naming convention to use for the chunked payload, the metadata convention used to store information about the chunked object, add the field added to a Content Object to represent the last chunk of an object. "CCNx End-To-End Fragmentation", marc.mosko@parc.com, 2015-07-01, This document specifies an end to-end fragmentation protocol for breaking a Content Object into several smaller pieces in order to fit within a network MTU. The fragmentation protocol does not provide a secure binding of the fragments to the original object. This is left to the receiving endpoint. Midpoints may only serve fragments from their cache if they have assembled and verified the complete Content Object. "CCNx Publisher Serial Versioning", marc.mosko@parc.com, 2015-01-09, This document specifies using a serial number to indicate versions in name name segments. A serial number is an increasing unsigned integer with an increment of 1. Therefore, given one name with a serial version number, one may compute the next version number. "Returning multiple answers in DNS responses.", Warren Kumari, Zhiwei Yan, Wesley Hardaker, 2015-07-06, This document (re)introduces the ability to provide multiple answers in a DNS response. "PIM fast recovery mechanism", Indranil Bhattacharya, 2015-01-12, When a PIM router reboots, either because of uncontrolled failover or because of ISSU, it needs to reconcile the PIM entries. For this, rebooting router sends PIM hello with new GenId. In reponse, neighbors send a new hello and replay PIM J/P message. Regardless an application maintaing full mroute states, the rebooting route must wait for this replay to complete only after which it can mark the oif reconciliation complete. This process is undeterministic today. This draft proposes a new mechanism to achieve a faster reconcilaition time. For this a new Hello option and a new message type has been introduced. "Intrusion Detection Parametrization Exchange Format (IDPEF)", Bjoern-C. Boesch, 2015-04-13, The Intrusion Detection Parametrization Exchange Format (IDPEF) defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from a Manager to an Analyzer. This Internet-Draft describes a data model to represent parametrization information of intrusion detection system entities, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, a XML Document Type Definition is developed, and parametrization examples are provided. "Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", Paul Kyzivat, 2015-01-20, This document defines and registers a value of "original-identity" for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). "RTP Payload for SMPTE ST 291 Ancillary Data", Thomas Edwards, 2015-01-13, This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). "Open Threat Signaling using RPC API over HTTPS and IPFIX", Nik Teague, 2015-07-04, This document defines a method by which a device or application may signal information relating to current threat handling to other devices/applications that may reside locally or at the service provider. The initial focus is ddos mitigation; however, the method may be extended to communicate any threat type. This will allow for a vendor or provider agnostic approach to threat mitigation utilising multiple layers of protection as the operator sees fit. The dissemination of threat information will occur utilising JSON RPC API over HTTPS communications between devices/applications and will be augmented by IPFIX and UDP or SCTP for signaling telemetry information relating to attacks and protected object data. An open standards based approach to communication between on-premise DDoS mitigation devices and service provider based DDoS protection services allows for enterprises to have a wider range of options to better secure their environments without the limitations of vendor lock-in. "RTP Payload for SMPTE ST 291 Ancillary Data", Thomas Edwards, 2015-01-27, This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). "Provisioning, Auto-Discovery, and Signaling in L2VPNs for IPv6 Remote PE", Avik Bhattacharya, Apratim Mukherjee, 2015-02-19, L2VPN Signaling specification defines the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when such discovery is based on the Border Gateway Protocol (BGP). This document updates the end point encoding for BGP-Based Auto-Discovery and specifies a format for NLRI encoding for IPv6 PE Address. This document also specifies a new type of attachment identifier to carry IPv6 address as AII in LDP FEC 0x81. This document updates RFC6074. "The Framework of Simplified Use of Policy Abstractions (SUPA)", Cathy Zhou, Luis Contreras, Qiong, Parviz Yegani, 2015-05-08, Currently, there are network services that impose specific demands on a communication network. This document describes the SUPA basic architecture, its elements and interfaces. The main SUPA architecture entities are the Service Management (SM) and the Network Manager/Controller (NM/NC). The SM is a functional entity that creates and runs network services by using a set of NM/NCs. The NM/NC is a functional entity that provides one or more of the following functions: (1) the generation, maintenance and release of network topologies, (2) the generation, maintenance, and release of network service-specific abstractions, (3) the mapping between network service-specific abstractions and the network topology, and (4) the mapping between network service-specific abstractions and network device configuration. Both the SM and the NM/NC may be made up of multiple distinct entities that collectively perform their functions. "LMAP Protocol Selection Criteria", Barbara Stark, Timothy Carey, 2015-03-01, This draft identifies criteria to be used by the LMAP WG in evaluating and selecting Control and Reporting Protocols described by [I-D.ietf-lmap-framework] and identified as WG deliverables in the LMAP charter. It is not intended for use for any other purpose or by any other party. This draft will not be maintained after LMAP completes its selection of these protocols. The authors of this draft do not intend to ask for working group adoption or formal publication by IETF. "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)", Greg Mirsky, Suchit Bansal, Ramanathan Lakshmikanthan, Israel Meilik, 2015-07-03, This document describes an OPTIONAL feature for active performance measurement protocols allowing use of time stamp format defined in IEEE-1588v2-2008. "Security Bootstrapping of IEEE 802.15.4 based Internet of Things", ana.hedanping@huawei.com, Behcet Sarikaya, 2015-05-05, Network level security bootstrapping and joining device level security bootstrapping mechanisms are described in this document. They are proposed for security bootstrapping of the Internet of Things networks, which implement IETF protocols (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. The network level security bootstrapping is useful at the very beginning of a newly deployed IoT network. It automatically and hierarchically adds all the devices to security domain and helps establish security communication. The joining device level security bootstrapping provides comprehensive mechanism for different IoT devices joining an existing IoT network. "Change Poll Extension for the Extensible Provisioning Protocol (EPP)", James Gould, Trung Tran, 2015-03-02, This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client sponsored objects that were not initiated by the client through EPP. These operations MAY include contractual or policy requirements including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. "AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer Security (TLS)", Aaron Zauner, 2015-06-01, This memo describes the use of the Advanced Encryption Standard (AES) in the Offset Codebook Mode (OCB) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-OCB algorithm is highly parallelizable, provable secure and can be efficiently implemented in software and hardware providing high performance. Furthermore, use of AES-OCB in TLS is exempt from past IPR claims by various parties. "OAuth 2.0 Security: OAuth Open Redirector", J. Bradley, Antonio Sanso, Hannes Tschofenig, 2015-01-20, This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification and in the OAuth 2.0 Threat Model and Security Considerations. "DHCP4o6 Bulk and Active Leasequery", Yong Cui, ZiLong Liu, Cong Liu, Yiu Lee, 2015-03-09, As networks migrate towards IPv6, some entities still have the requirement for IPv4 configuration. DHCPv4 over DHCPv6 [RFC7341] provides a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks. DHCPv4/DHCPv6 Bulk Leasequery and Active Leasequery allow a client to get DHCP address binding information data in bulk transfer or in real-time via TCP. This document describes an extension of DHCPv6 Bulk and Active Leasequery that provides a mechanism to get DHCPv4 over DHCPv6 lease information. "Identifier-locator addressing for network virtualization", Tom Herbert, 2015-01-21, This specification describes identifier-locator addressing (ILA) in IPv6 for network virtualization. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. In the context of virtualization, a virtual address serves as an identifier and the address of the host where the associated tenant system currently resides is a locator. "Client-Inserted Client Link-Layer Address Options in DHCPv6", Fred Templin, 2015-01-22, RFC6939 specifies a method for DHCPv6 relay agents to insert a Client Link Layer Address Option (CLLAO) in a DHCPv6 Relay-Forward message. In some cases, however, the DHCPv6 client may need to insert a CLLAO in its message on its own behalf even though it is on the same link as the DHCPv6 server. This document discusses client-inserted CLLAOs. "OAuth 2.0 Security: OAuth Open Redirector", J. Bradley, Antonio Sanso, Hannes Tschofenig, 2015-03-23, This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification and in the OAuth 2.0 Threat Model and Security Considerations. "An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX)", Yoshihiro Ohba, 2015-06-28, This document defines an extension of MLE (Mesh Link Establishment) protocol to encapsulate HIP DEX key exchange protocol messages. "A YANG Data Model for Service Topology", Zitao Wang, Qin Wu, Susan Hares, 2015-03-05, This document defines a YANG data model for Service Function Forward Topology. This I2RS yang data model is part of the I2RS protocol independent topology set of data models. "Multi-party Multi-Domain Trust Architecture Recommendations for SDN Deployment in Carrier Network", saurabhchattopadhya@hcl.com, Kaushik Datta, 2015-01-23, This draft analyzes implementation methodologies for addressing the security requirements of SDN adopted network architecture through Public Key Infrastructure. The draft analyzes the relevant design patterns of PKI based Trust Models to address the challenges faced during SDN Adoption. And, the draft defines the considerations for setting up a Trust Relationship Management framework suitable for PKI based SDN integrated environment. "Routing Policy Configuration Model for Service Provider Networks", Anees Shaikh, Rob Shakir, Kevin D'Souza, Chris Chase, 2015-07-04, This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way and based on actual operational practice. The model provides a generic policy framework which can be augmented with protocol-specific policy configuration. "The YANG Conformance Problem", Martin Bjorklund, 2015-02-18, This document describes the YANG conformance problem. It is intended as a temporary document to help the NETMOD WG in the design of YANG 1.1. "A Network Policy YANG Data Models using abstraction language", Zitao Wang, 2015-05-04, This document describes a YANG data model for network policies using Language Abstractions defined in RFC6095. The model intends to be applied to deliver various different network services by controlling the policies that enable features such as QoS, Security, etc. In future, the core data model could be augmented by additional YANG data modules modeling and configuring policy-related protocols and functions. The policy data model described in this document provides common building blocks for such extensions. Earlier revisions of this document were written to trigger discussion with operator community at IETF-92 in Dallas. This document has been updated to reflect the limited conclusions of those discussions and record them for archival purposes. There is no intent to advance this document any further toward publication. "Content-Centric Networking Packet Header Format", Massimo Gallo, Diego Perino, luca.muscariello@orange.com, 2015-01-26, This document describes an experimental header format for CCN packets. The header is composed of a set fixed size fields followed by a set of Type-Length-Value fields in order to define a flexible, compact and easy to parse packet format for the CCN protocol. "SDP-based "SCTP over DTLS" data channel negotiation", Keith Drage, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-01-26, 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, where each data channel might be used to transport other protocols, called sub-protocols. Data channel setup can be done using either the internal in-band band (also referred to as 'internal' for the rest of the document) WebRTC Data Channel Establishment Protocol or some external out-of-band simply referred to as 'external negotiation' in the rest of the document . This document specifies how the SDP offer/answer exchange can be used to achieve such an external 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. This document is intended to be used wherever data channels are used. "MSRP over SCTP/DTLS data channels", Keith Drage, Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2015-01-26, This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. 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). "Routing Extensions for Discovery of Role-based MPLS Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership", Zhenbin Li, Mach Chen, Greg Mirsky, 2015-01-27, A Traffic Engineering (TE) mesh-group is defined as a group of Label Switch Routers (LSRs) that are connected by a full mesh of TE LSPs. Routing protocol (OSPF and IS-IS) extensions facilitate discovery of Multiprotocol Label Switching (MPLS) LSR TE mesh membership and automate the creation of a full mesh of TE LSPs. This document introduces a role-based TE mesh-group that applies to the scenarios where full mesh TE LSPs are not necessary and TE LSPs setup depends on the roles of LSRs in a TE mesh-group. Interior Gateway Protocol (IGP) routing extensions for automatic discovery of role-based TE mesh membership are defined accordingly. "IPv4 with 64 bit Address Space", William Chimiak, 2015-04-15, This document describes a solution to the Internet address depletion problem through use of a clever IPv4 options mechanism as a solution. This IPv4 protocol extension is called enhanced IP (EnIP). Because it is IPv4, it maximizes backward compatibility while increasing address space by a factor of 17.9 million. Unlike other similar proposals, care was taken to avoid costly changes and requirements to the core network and border routers, with the exception that options be passed in that equipment as described below. Because it is backward compatible, current IPv4 software, network equipment, firewalls, intrusion detection/protection, and layer 5 firewalls can be maintained until IPv6 system information security reaches acceptable maturity and availability. "Information Model of Interface to Network Security Functions Capability Interface", Liang Xia, Ed, Dacheng Zhang, Nicolas Bouthors, 2015-06-30, This draft is focused on the north-bound interface of NSFs (Network Security Functions) and proposes an information model for configuring various kinds NSF security functions, based on the packet-based paradigm. The Yang structure and application examples are also presented to clarify how to use the information model. "Automatic Certificate Management Environment (ACME)", Richard Barnes, Jacob Hoffman-Andrews, James Kasten, 2015-07-06, 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. "A YANG Data Model for NTP", Nan Wu, 2015-06-27, This document defines a YANG data model for Network Time Protocol implementations. The data model includes configuration data and state data. "Selection of MPLS LSP's based on Loss and Delay Measurement values.", sureshkb@juniper.net, 2015-01-30, MPLS is the heart and soul of the service provider network. MPLS can carry any data payload which gives the flexibility to the service provider to provision new service with any expense. As loss and delay sensitive applications such as Voice and Video are running on MPLS network, they may suffer delays in packet transmission and delivery. So Voice and Video traffic on MPLS network needs low loss and delay LSP's to transfer Voice and Video packets. This draft is proposing a solution to selection of Low loss and latency LSP's for Voice and Video applications using MPLS Loss and Delay measurement parameters. The benefit of this technology results in delivery voice and video packets with best possible lsp i.e. LSP's with less loss and delay. "L3VPN Address Prefix Based Outbound Route Filter for BGP-4", Xiaohu Xu, Christian Jacquenet, Luyuan Fang, 2015-04-29, This document defines a new Outbound Router Filter (ORF) type for BGP, refered to as "L3VPN Address Prefix Outbound Route Filter", that can be used to perform L3VPN address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild- card-based address prefix matching, as well as the exact address prefix matching for L3VPN address families. The L3VPN Address Prefix ORF is applicable in the Virtual Subnet context. "RIB Reduction in Virtual Subnet", Xiaohu Xu, Susan Hares, Fan Yongbing, Christian Jacquenet, Truman Boyes, Brendan Fee, 2015-01-31, Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution which is intended for building Layer3 network virtualization overlays within and/or across data centers. This document describes a mechanism for reducing the RIB size of PE routers in the Virtual Subnet context. "Relay Chaining in DHCPv4", sureshkb@juniper.net, 2015-01-31, DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. In certain network configurations, a DHCP server may be multiple subnets away from the DHCP client and multiple Relay Agents may be configured to relay DHCP messages to and from DHCP client. Such configuration can be supported only when each Relay Agent adds certain Information to DHCP messages before relaying them. This additional information helps in relaying the DHCP reply back to the DHCP client through the same path. This mechanism is referred as Relay Chaining. "The BLAKE2 Cryptographic Hash and MAC", Markku-Juhani Saarinen, Jean-Philippe Aumasson, 2015-06-30, This document describes the cryptographic hash function BLAKE2, making the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms, and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC). "VPN Service Management YANG Data Model", Dacheng Zhang, Adel Zaalouk, Ying Cheng, Jan Lindblad, Maxim Klyus, 2015-05-11, Currently new services create new opportunities for both network providers and service providers. Simplified Use of Policy Abstractions (SUPA) was proposed to develop a model that abstracts network resources and services and a methodology by which the management and monitoring of network services can be done using standardized policy rules. This document defines a VPN service management yang data model and gives an example for DDC use case. "Internet Exchange Route Server - Implementation Report", Elisa Jasinska, 2015-02-02, This document provides a survey of Internet Exchange Route Server implementations. "YANG Data Models for Intent-based NEtwork MOdel", Tianran Zhou, Shixin Liu, Yinben Xia, Sheng Jiang, 2015-02-02, This document describes a basic YANG data model for network intent. The basic model can be augmented by additional YANG modules defining data models for intent related protocols and functions to support various network scenarios and applications. The basic network intent data model provides common building blocks for extensions, such as specific node and policy information. "Secure DHCPv4", Sheng Jiang, Dacheng Zhang, 2015-06-24, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) enables DHCPv4 servers to pass configuration parameters. It offers configuration flexibility. If not being secured, DHCPv4 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv4 and specifies a Secure DHCPv4 mechanism for communications between DHCPv4 clients and servers. This document provides a DHCPv4 client/server authentication mechanism based on sender's public/private key pairs or certificates with associated private keys. The DHCPv4 message exchanges are protected by the signature option and the timestamp option newly defined in this document. "IP address privacy by TURN server", Tirumaleswar Reddy, Prashanth Patil, 2015-02-04, A TURN server allocates an IP address for a user. If this address is dis-associated from the user's actual network, the allocated IP address increases the user's privacy. This document describes a means for an client to discover that the TURN server can provide IP address privacy. "PPPoE-Bulk-Session Tag extension to PPPoE PADT message", Srinivasa Nalluri, 2015-05-14, This draft introduces a new PPPoE Tag to PADT message to carry multiple PPPoE session information to BRAS. New tag is intended to reduce processing load on Access Node and BRAS in abnormal network conditions. "Remote Call Control and Call Pick-up in SIP", Anton Tveretin, 2015-02-05, This memo defines a mechanism by which a SIP user agent could inspect calls at another user agent, and control a call, including picking up for itself. "Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping", James Gould, Francisco Obispo, 2015-04-02, This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy. The IDN Table information can be used to validate an IDN prior to registration, can be cached by the client for pre-validation, can be used to select the best IDN Table for the IDN, and can be used to know if and what IDN Table Identifier to pass in a domain create. "Handshaking mechanism for DF election", Hao Weiguo, Lucy Yong, LQD, 2015-05-11, In [EVPN], in the DF re-election transient period, due to Ethernet Segment route transmission timer and timer clock discrepancy on each PEs, dual DF PEs will co-exist, traffic loop and disruption will be incurred. In MHN case, the consequences are particularly serious. Handshaking mechanism for DF election is introduced in this draft to resolve the problem. "Tenant Traffic Handling in NVO3", Zu Qiang, 2015-02-06, This draft discusses the considerations on how to handle the tenant traffic in NVO3 architecture and several related issues which need to be considered when designing a NVO3 based virtualized data center network for multiple tenants. "SDNauth Usecases and Requirements", Hosnieh Rafiee, Alex Petrescu, 2015-06-05, This document aims to explain the requirement and usecases for a secure authentication model for different SDN components (e.g. SDN switch, application, etc.). It also covers the standard structure for the communications of two SDN controllers or an application to different SDN controllers via a mediator service. "EdDSA and Ed25519", Simon Josefsson, Niels Moller, 2015-05-12, The elliptic curve signature scheme EdDSA and one instance of it called Ed25519 is described. An example implementation and test vectors are provided. "RSVP Extensions for Dynamic Reservation", Robert Chodorek, Agnieszka Chodorek, 2015-06-15, RSVP reservations are static in nature and typically last for the whole session. The proposed extension to the RSVP allows the RSVP to make elastic adjustments to reservations for the current demand of network resources. The proposed method dynamically changes the RSVP reservations on the basis of knowledge about transmitted traffic. "Combining TCP with coding in wireless network", wangjinzhu, Deng Lingli, 2015-02-07, This drat discusses combining TCP with coding in wireless network. A lot of factors lead to unstable air-link in wireless network, which causes high bit error rate and thus high packet loss. Since packet loss will degrade TCP throughput and coding can erase packet loss in transmission, combing TCP with coding can achieve better performance. "Early Event-Driven (EED) RTCP Feedback for Rapid IDMS", Mario Montagud, Fernando Boronat, Hans Stokking, 2015-02-09, RFC 7272 defines two RTCP messages to enable Inter-Destination Media Synchronization (IDMS). However, if such RTCP messages are exchanged using the Regular RTCP reporting rules specified in RFC 3550, unacceptable delays can be originated when exchanging the synchronization information conveyed into RTCP packets. Accordingly, this document proposes Early Event-Driven (EED) RTCP reporting rules and messages to enable higher interactivity, dynamism, flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are targeted at providing faster reaction on dynamic situations, such as out-of-sync situations and channel change delays, as well as a finer granularity for synchronizing media-related events, while still adhering to the RTCP bandwidth bounds specified in RFC 3550. Besides, a new RTP/AVPF transport layer feedback message is proposed to allow the request of re-IDMS setting instructions (e.g., in case of RTCP packet loss) as well as rapid accommodation of latecomers in on-going sessions. Finally, this document also discusses various situations in which the reporting of Reduced-Size RTCP packets (RFC 3556) can be applicable and beneficial for IDMS. "Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions", Matthew Thomas, Allison Mankin, Lixia Zhang, 2015-02-09, This document provides context and a report of a workshop on Root Causes and Mitigation of Name Collisions, which took place in London, United Kindgdom, on March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context, then provides a summary of the workshop's discussions. "Substrate Protocol for User Datagrams (SPUD) Prototype", Joe Hildebrand, Brian Trammell, 2015-03-09, SPUD is a prototype for grouping UDP packets together in a "tube", also allowing network devices on the path between endpoints to participate explicitly in the tube outside the end-to-end context. "Interface to Network Security Functions Information Model", John Strassner, Liang Xia, 2015-02-09, This document describes an information model that defines the salient managed entities and their relationships in an Interface to Network Security Function (I2NSF) architecture. The information model is independent of platform, language, and protocol, and serves as a common consensual lexicon for the I2NFS architecture as well as clients using this architecture. This enables multiple application- specific data models (which are dependent on platform, language, and/or protocol) to be built from this information model. The advantage of doing so is to ensure that such data models will be able to share and reuse consensually defined concepts, thereby increasing interoperability. "Data Model of Interface to Network Security Functions Service Interface", Liang Xia, John Strassner, Dean Bogdanovic, 2015-02-09, This draft proposes a generic and intent-driven data model for NSF security policy configuration used by I2NSF clients to negotiate their security requirements with various kinds of entities that each provide one or more NSFs. The Role Based Access Control (RBAC) reference model [INCITS359 RBAC] is used to represent which operations can be performed on what set of secured objects. "Homenet IS-IS and Babel Comparison", Margaret Wasserman, Christian Hopps, Juliusz Chroboczek, 2015-03-05, This document is intended to provide information to members of the IETF Home Networks Working Group (Homenet WG), so that we can make an informed decision regarding which routing protocol to use in home networks. The routing protocols compared in this document are: The Babel Routing Protocol (Babel) and The Intermediate System to Intermediate System Intra-Domain Routing Protocol (IS-IS). "YANG Data Model for Application Intelligent Service Profiles (ALPS)", Pang Tao, Rachel Huang, 2015-02-09, This document introduces a common YANG data model for network service profile. The common model can be augmented by additional YANG modules defining data models for specific network services to support various different network service consumers. "Use Cases for SPUD", Ted Hardie, 2015-02-12, SPUD is a prototype for grouping UDP packets together. This grouping allows on-path network devices, especially middleboxes such as NATs or firewalls, to understand some basic semantics and potentially to offer salient information about their functions or the path to the endpoints. This document describes basic use cases for sharing that semantic and for using the information shared. "Yang Data Model for LSP-PING", Lianshu Zheng, Sam Aldrin, Guangying Zheng, Greg Mirsky, Reshad Rahman, 2015-07-03, When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. RFC4379 defines a mechanism that would enable users to detect such failure and to isolate faults. YANG [RFC6020] is a data definition language that was introduced to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF RFC[6241]. This document defines a YANG data model that can be used to configure and manage LSP-Ping. "Loopback Prefix for IPv6", Edward Lewis, 2015-02-12, The IPv6 address range of 0::/64 is reserved for loopback addresses. This expands from the single loophack address already defined for IPv6, ::1, to allow for a set of addresses to be used when packets are intended to stay within a host system. Multiple loopback addresses allow for simultaneous varied uses of the loopback addresses as has proven, albeit in limited ways, in IPv4. And exception is made to accomodate the ::0/128, already defined as The Unspecified Address. "Internet Media Type application/sdpfrag", Emil Ivov, Adam Roach, 2015-02-12, This document registers the application/sdpfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to application/sdp, but allows certain subsets of well formed session descriptions, as per the Session Description Protocol (SDP), to be represented instead of requiring a complete SDP session description. The "a=candidate" lines that are incrementally exchanged between Trickle ICE agents are one example usage of the application/sdpfrag. "BGP Tunnel Encapsulation Attribute for UDP", Xiaohu Xu, Rajiv Asati, 2015-06-17, This document specifies a new Border Gateway Protocol (BGP) Tunnel Type of User Datagram Protocol (UDP) tunnels. "YANG model classification", Dean Bogdanovic, Benoit Claise, Carl Moberg, 2015-06-03, The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards organizations and open source projects are using YANG to develop and publish models of configuration, state data and operations for a wide variety of networking applications. At the same time, there is currently no well-known terminology to categorize the various types of YANG models that are being worked on. A consistent terminology would help with the categorization of models, assist in the analysis the YANG data modeling efforts in the IETF and in other places, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG models. "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia, 2015-02-13, This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD [RFC5880]. "Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation", Chris Bowers, Janos Farkas, 2015-07-03, IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] uses the algorithm specified in [I-D.ietf-rtgwg-mrt-frr-algorithm] to compute Maximally Redundant Trees (MRTs) to be used for the protection of data traffic in bridged networks. This document discusses the applicability of the MRT algorithm to 802.1Qca. "DDC Service Policy YANG Data Model", Jun Bi, Raghavendra Tadepalli, Michiaki Hayashi, 2015-05-08, This document describes a YANG data model for traffic steering policies in Distributed Data Center (DDC) scenarios. The policy model is a specific data model for traffic steering using VPN technology. It helps the service management in Simplified Use of Policy Abstractions (SUPA) to model the policy (a set of constraints and rules) that defines how a VPN service is monitored by bandwidth and managed during its lifecycle. Two traffic steering applications have been provided such as traffic optimization with pass or bypass specific nodes or sites. "ACTN Use-case for Multi-domain Operation Plane Change", Toshiaki Suzuki, 2015-02-16, This document provides a use-case that addresses the need for facilitating dynamic change of an operation plane, which includes multiple virtual networks and/or data transmission paths, from a current operation one to a backup one during a scheduled maintenance or an emergency such as network disaster. Specifically, the necessity of interfaces between domain management systems to establish consistent end-to-end data transmission paths over multiple domain networks is addressed. "Advertising Per-node Admin Tags in BGP Link-State Advertisements", P. Sarkar, Hannes Gredler, Stephane Litkowski, 2015-02-16, This document describes the protocol extensions to collect per-node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same per-node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. "Enabling Security/Privacy Addressing On 6LoWPAN Technologies", Dave Thaler, 2015-02-16, It is commonly assumed today that 6LowPAN header compression is incompatible (or at least inefficient) with the notion of using addresses with sufficient entropy to mitigate various security and privacy threats. This draft explores ways one might dispel that notion, and discusses how security/privacy addressing might be used on 6LoWPAN technologies without additional overhead in data packets. "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, 2015-05-27, 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. "Universal 2nd Factor (U2F) Authentication for Secure Shell (SSH)", Michael Stapelberg, Simon Josefsson, 2015-02-17, Universal 2nd Factor (U2F) is an authentication factor intended to strengthen other authentication mechanisms. This document describe how U2F can be used to strengthen Secure Shell authentication mechanisms. "The Jabber Scribe Role at IETF Meetings", Peter Saint-Andre, york@isoc.org, 2015-06-04, During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers, commonly called "Jabber scribes", might benefit from the suggestions provided in this document. "Requirements and reference architecture for Mobile Throughput Guidance Exposure", Ankur Jain, Andreas Terzis, Nurit Sprecher, Swaminathan, Kevin Smith, Guenter Klas, 2015-02-20, Rapidly-varying conditions in a cellular network can cause problems for the Transmission Control Protocol (TCP), which in turn can degrade application performance. This document presents the problem statement and proposes solution principles. It specifies the requirements and reference architecture for a mobile throughput guidance exposure mechanism that can be used to assist TCP in cellular networks, ensuring better network efficiency and enhanced service delivery performance. The proposed mechanism can be applied to any content or TCP/IP based application content delivery. This document describes the applicability of the mechanism for Intelligent Video Acceleration over cellular networks. "Extensions of httpd or webserver to allow configruing incoming FAX by ISP's", pradeep xplorer, 2015-02-21, This document describes the need for a FAX recieving services that can be easily supported by a ISP who can afford a fax machine and those who own domains and websites using ISPs should be able to recieve FAX. "Path validation toward BGP next-hop", Jerome Durand, 2015-02-22, This proposal introduces a new BGP attribute that can be used by BGP routers to advertise their capability to support any kind of host liveliness checking protocols (for example BFD). This attribute can be used to avoid black-holes scenarios seen when BGP next-hop is not the peer, in particular on Internet eXchange Points (IXPs) implementing BGP Route-Servers. IXP member routers can exchange their capability to implement a given host liveliness checking Foreword A placeholder to list general observations about this document. "Destination Claim for JSON Web Token", Brian Campbell, Guoping Liu, 2015-02-23, The Destination Claim for JSON Web Token (JWT) provides a means of indicating the address to which the JWT is sent. The Claim can be used to preventing malicious forwarding or redirection of a JWT to unintended recipients. "A Survey of the DNS cache service in China", Wei Wang, Zhiwei Yan, 2015-02-24, DNS cache directly serves the DNS queries from stub resolvers as the data source in the specified network area. For the present, however, operators manage and run the cache service in a diversified manner. This arouses the main motivation of this survey report. Instead of regulating or specifying the operation of the DNS cache service, our aim is to investigate the situation of the DNS cache service (at least in mainland China) and propose the future operation recommendations with solid practical foundation. "DTN Security Key Management - Requirements and Design", Fred Templin, Scott Burleigh, 2015-02-25, Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. These challenges render traditional security key management mechanisms infeasible since round trip delays may exceed the duration of communication opportunities. This document therefore proposes requirements and outlines a design for security key management in DTNs. "CAPWAP Control and Data Channel Separation for Multi-provider Scenario", Jianjie You, Haibin Song, Rong Zhang, 2015-05-25, The CAPWAP control channel and data channel split architecture has some benefits, such as relieving the capacity pressure of the AC. However, the current documents are not specific to the multi-provider scenario. This document discusses the third-party WLAN service provider scenario (i.e. Virtual Network Operator, VNO), and proposes to extend CAPWAP for supporting this use case. "Use Cases and API Extension for Source IP Address Selection", Seil Jeon, Sergio Figueiredo, Young-Han Kim, 2015-06-24, This draft specifies and analyzes the expected cases regarding the selection of a proper source IP address and address type based on the application features over a distributed mobility management (DMM) network. It also provides available selection methods to better achieve DMM goals in the specified scenarios. "Inter-AS Option B between NVO3 and BGP/MPLS IP VPN network", Hao Weiguo, Lucy Yong, Susan Hares, Robert Raszuk, Luyuan Fang, Osama Zia, Shahram Davari, Andrew Qu, 2015-05-18, This draft describes the solution of inter-as option-B connection between NVO3 network and MPLS/IP VPN network. The ASBR located in NVO3 network is called ASBR-d, the control plane and data plane procedures at ASBR-d are specified in this document, there are some differences from traditional option-B ASBR defined in [RFC 4364]. "Source Address Dependent Route Information Option for Router Advertisements", Pierre Pfister, 2015-06-22, This document defines the Source Address Dependent Route Information option for Router Advertisements, enabling source address dependent routes to be installed in hosts by neighboring routers. It also adds a new flag to the existing Route Information option for backward compatibility purposes. "STUN Traceroute", Paal-Erik Martinsen, Dan Wing, 2015-06-01, After a UDP protocol such as RTP determines a network path is experiencing problems, a traceroute is often useful to determine which router or which link is contributing to the problem. However, operating system traceroute commands follow a different path than the actual UDP flow which complicates troubleshooting. A superior method is shown which is absolutely path-congruent with the UDP protocol itself, works on IPv4 and IPv6, and does not require administrative privileges on most operating systems. "Multi-homing of NVEs", Mingui Zhang, Muhammad Durrani, Margaret Wasserman, 2015-02-27, Multi-homing of NVEs is a desirable feature to NVO3 since it provides Tenant Systems with reliable connection, load-balance, etc. The major issue of the multi-homing of NVEs is that it introduces one-to-many mapping from Tenant System (inner) addresses to NVE (outer) addresses. This document identifies the requirements for multi-homing of NVEs and specifies corresponding solutions to meet these requirements. The key is to let remote NVEs be aware of the group of NVEs that are offering multi-homing to Tenant Systems, therefore the remote NVE can cope with the one-to-many mapping correctly. "Advertising Tunnelling Capability in OSPF", Xiaohu Xu, Bruno Decraene, Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2015-06-30, Some networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the ingress needs to select a type of tunnel which is supported by the egress. This document defines how to advertise egress tunnel capabilities in OSPF Router Information. "Indoor Location Mechanisms for Emergency Services", Roger Marshall, Marc Linsner, Dorothy Stanley, 2015-03-01, The application of summoning emergency assistance by using a phone to call 9-1-1 in North America has been ingrained in society for 40+ years. A successful emergency response to a caller in need, is dependent upon the responders receiving accurate location information to effect timely action. Traditional wireline telephony is able to utilize the location of the physical wires as a source of information for caller location, whereas wireless technologies require more exotic mechanisms to locate a 9-1-1 caller. Mechanisms for locating a cellular caller dialing 9-1-1 is based on 20 year old technology, which was designed for outdoor environments, and does not perform sufficiently when used to locate an emergency caller from within a home or office building environment. With growing trends in mobile cellular usage, large portions of subscribers are relying solely on their mobile phones to make emergency calls. Emergency response time suffers when that caller is located indoors. This document defines the problem statement and solutions for expanding the current set of methods used to locate a cellular caller to 9-1-1. The expansion of the methods includes connections to services that are outside the normal administrative domain of the cellular provider, hence both the privacy and security aspects of connecting these systems are taken into consideration. "On the Need for Transport Protocol Profiles & Investigating New Evolution Tracks", Mohamed Boucadair, David Binet, Christian Jacquenet, Luis Contreras, Yiu Lee, 2015-03-06, The world of Internet transport protocols is changing, after decades of TCP and UDP operation. Several proposals have been submitted for the past years (and counting) to introduce other transport protocols that aim at reducing the web latency of that of TCP or avoiding the burden of the various middle-boxes (NATs, firewalls, for one) encountered along the communication path. Such initiatives, although not new, are motivated by the complexity of some (non-transparent) networking functions. This document advocates for the definition of transport profiles and the need to document recommendations for middleboxes, including Performance Enhancement Proxies (PEPs) behaviors. A collaboration among the involved players (service providers, vendors) is required to soften the current complications encountered in the Internet at large. "Using DANE to associate payment information with email addresses", Glen Wiley, Eric Osterweil, David Smith, Alan Reiner, Douglas Roark, 2015-03-02, There is no standard, interoperable method for associating Internet service identifiers with payment information. This document specifies a means for retrieving information sufficient for a party to render payment using various payment networks given the recipient's email address by leveraging the DNS to securely publish payment information in a payment association record. A payment association record associates an Internet service identifier such as an email address with payment information such as an account number or Bitcoin address. "RFC6374 Synonymous Flow Labels", Stewart Bryant, George Swallow, Siva Sivabalan, Greg Mirsky, Mach Chen, Zhenbin Li, 2015-07-04, [Editor's note - there was a comment that synonymous was not the right term because synonymous implied a greater degree of interchangeability than is actually the case (there is only one way interchangeability). I have looked for other terms, and so far I have only come up with enhanced and multi-purpose, but they are not quite right either. I plan to continue with the term unless anyone has a better idea.] This document describes a method of providing flow identification information when making RFC6374 performance measurements. This allows RFC6374 measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374. "A Control Protocol for Synonymous Flow Labels", Stewart Bryant, George Swallow, Siva Sivabalan, 2015-03-02, In draft-bryant-mpls-synonymous-flow-labels the concept of MPLS synonymous flow labels (SFL) was introduced. This document describes a control protocol that runs over an associated control header to request, withdrawn and extend the lifetime of such labels. "RFC6374 over UDP", Stewart Bryant, George Swallow, Siva Sivabalan, 2015-03-02, In draft-bryant-mpls-synonymous-flow-labels the concept of MPLS synonymous flow labels (SFL) was introduced and it was shown how they could be used to support RFC6374 loss measurements. In draft-bryant- mpls-sfl-control the request, lifetime management and withdrawal of SFLs was described. In this memo we show how these two protocols can be run over UDP to support the operation of RFC6374 in systems that do not support the Generic Associated Channel Label (GAL) (RFC5586). "IPv6 RA Option for Source Address Dependent Routing", Behcet Sarikaya, 2015-06-08, This document proposes the router advertisement extensions for source address dependent routing. New Router Advertisement option is defined for configuring route prefixes and their corresponding source prefixes on the mobile or fixed nodes. Using this option, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. The option is defined together with definitions of host and router behaviors. "A Data Model for Network Inventories", Jie Dong, Mach Chen, 2015-03-02, This document defines a YANG data model for network inventories. "Key Managed JSON Web Signature (KMJWS)", Michael Jones, 2015-05-27, Key Managed JSON Web Signature (KMJWS) represents content that is integrity protected with a Message Authentication Code (MAC) in which key management is employed for the MAC key. This representation reuses key management functionality already present in the JSON Web Encryption (JWE) specification and MAC functionality already present in the JSON Web Signature (JWS) specification. "An Extension to MPTCP for Symmetrical Sub-Flow Management", Mohamed Boucadair, Christian Jacquenet, 2015-03-09, This document specifies a MPTCP extension that allows to achieve symmetrical subflow management. In particular, this extension allows both endpoints to add new subflows whenever needed without waiting for the endpoint which initiated the first subflow to add new ones. This document updates RFC 6824. "DMARC Author Align", Douglas Otis, 2015-03-04, Deals with DMARC acceptance failures disrupting legitimate and valid message distribution affecting millions while attempting to exclude From header field domains not aligned with email acceptance methods in a manner incompatible with normal email conventions. DMARC does not accommodate recent message structure underscoring the erroneous premise of a store-and-forward transport enforcing non-negotiable message structure. Active exploitation of DMARC dependency on flawed acceptance practices are further aggravated when its feedback is sent to malefactors. Risks prevented by careful accommodation of legitimate and valid messages also better ensures economic, social, and civic benefits derived from an open exchange of email. "Client Link-Layer Address Option (CLLAO) Updates", Fred Templin, 2015-03-03, RFC6939 specifies a method for DHCPv6 relay agents to insert a Client Link Layer Address Option (CLLAO) in a DHCPv6 Relay-Forward message as informational material for the DHCPv6 server. The server in turn is not required to echo the CLLAO back in its replies. In some cases, however, the DHCPv6 client may be interested to receive the CLLAO, e.g., to determine if there are L2 devices (e.g., L2 proxies) that rewrite the link-layer address. This document discusses updates to RFC6939 to allow the server to echo the CLLAO back to the client. "A generic YANG Data Model for Label Switch Path (LSP).", Xian Zhang, Dhruv Dhody, 2015-03-03, This document defines a generic YANG data model for the Label Switch Paths (LSPs). The data model includes the operational state of LSP (LSP-DB). It is expected that this modules will be augmented by additional YANG modules defining data models for signalling protocol and other functions. "MPTCP Connectivity Checks", Mohamed Boucadair, Christian Jacquenet, 2015-03-04, This document specifies an extension to minimize the delay induced by the presence of MPTCP-unfriendly nodes in some of the paths selected by a MPTCP endpoint, and which may support the establishment of MPTCP subflows. Concretely, this procedure allows a MPTCP endpoint to assess whether the networks the endpoint connects to are compliant with MPTCP signals or not. The procedure is not enabled for every new MPTCP connection; it is activated upon bootstrap or when a network attachment change occurs (e.g., attach to a new network, discover a new external IP address, etc.). "Security Bootstrapping over IEEE 802.15.4 in selective order", Sandeep Kumar, Peter Van der Stok, 2015-03-04, Low-resource devices in a Low-resource and Lossy Network (LLN) can be based on a mesh network using the IEEE 802.15.4 link standard. Security in these networks MUST be enforced at the link level. Provisioning the devices in a secure manner with keys (often called security bootstrapping) to encrypt and authenticate the link-layer messages is the subject of this specification. This proposal distinguishes itself from other bootstrap proposals by requiring that the devices can be secured in an order determined by the needs of the installation procedure. Other proposals use an "onion model", where first the devices one-hop away from the initial device (often the border router) are secured, followed by the devices that are one-hop away from already secured devices. "Service Function Simple Offloads", Surendra, Jim Guichard, Paul Quinn, Joel Halpern, 2015-03-04, Service Function Chaining (SFC) enables services to be delivered by selective traffic steering through an ordered set of service functions. Once classified into an SFC, the traffic for a given flow is steered through all the service functions of the SFC for the life of the traffic flow even though this is often not necessary. Steering traffic to service functions only while required and not otherwise, leads to shorter SFC forwarding paths with improved latencies, reduced resource consumption and better user experience. This document describes the rationale, techniques and necessary protocol extensions to achieve such optimization, with focus on one such technique termed "simple offloads". "Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Jeffrey Zhang, 2015-03-04, 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. "IGP Multicast Architecture", Lucy Yong, Dean Cheng, Hao Weiguo, Donald Eastlake, Andrew Qu, Jon Hudson, Uma Chunduri, 2015-03-09, This document specifies the architecture of IP multicast routing using an Interior Gateway Protocol (IGP). "Deterministic Networking Professional Audio Requirements", Craig Gunther, Ethan Grossman, 2015-03-31, This draft documents the needs in the professional audio and video industry to establish multi-hop paths and optional redundant 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 a Layer 3 (IP) interface. "Host Identification/Address Problem in Service Function Chaining Use Cases", Chongfeng Xie, Shucheng LIU, 2015-03-04, The purpose of this document is to present host identification problem due to the address and prefix sharing in service function chaining. We have identified this problem in the use cases of the parental control service and offloading service in home networks and also some use cases in mobile networks. "Inter-AS Option B between NVO3 and BGP/MPLS IP VPN network through centralized architecture", Hao Weiguo, Lucy Yong, Susan Hares, Robert Raszuk, Luyuan Fang, Osama Zia, Shahram Davari, Andrew Qu, 2015-03-04, This draft describes the solution of vanilla inter-as option-B connection between NVO3 network and MPLS/IP VPN network through centralized NVE-NVA architecture. The ASBR located in NVO3 network is called ASBR-d, NVO3 tunnel and MPLS tunnel stitching should be performed on the ASBR-d. No distributed BGP VPN protocol (RFC4364) is running between NVEs and ASBR-d in NVO3 network, NVEs and ASBR-d are controlled by centralized NVA. "Layer-Transcending Traceroute for Overlay Networks like VXLAN", Erik Nordmark, Chandra Appanna, Alton Lo, 2015-03-04, Tools like traceroute have been very valuable for the operation of the Internet. Part of that value comes from being able to display information about routers and paths over which the user of the tool has no control, but the traceroute output can be passed along to someone else that can further investigate or fix the problem. In overlay networks such as VXLAN and NVGRE the prevailing view is that since the overlay network has no control of the underlay there needs to be special tools and agreements to enable extracting traces from the underlay. We argue that enabling visibility into the underlay and using existing tools like traceroute has been overlooked and would add value in many deployments of overlay networks. This document specifies an approach that can be used to make traceroute transcend layers of encapsulation including details for how to apply this to VXLAN. The technique can be applied to other encapsulations used for overlay networks. It can also be implemented using current commercial silicon. "Autonomic Distributed Node Consensus Protocol", Markus Stenberg, 2015-03-05, This document describes the Autonomic Distributed Node Consensus Protocol (ADNCP), a profile of Distributed Node Consensus Protocol (DNCP) for autonomic networking. "Named data networking for social network content delivery", Patrick Truong, Klaus Satzke, Bertrand Mathieu, Emile Stephan, 2015-03-05, Online Social Networking (OSN) applications have attracted millions of people over the last few years. Their traffic represents a large part of the traffic of the Internet. For instance, Facebook represents near 25 percent of the Internet traffic [14][15], and a part of this traffic is exchanged amongst groups of end-users which are located in the same geographic area. In this document, we introduce a Named Data Networking (NDN) architecture to improve the delivery of OSNs contents requested by end-users in the neighbourhood of the publishers: Having the knowledge of the social network graph and the end-users network location, a SDN-based NDN controller dynamically configures the NDN routers to route the interest requests directly between the end-users. "A packet based method for passive performance monitoring", Alessandro Capello, Mauro Cociglio, Giuseppe Fioccola, Luca Castaldelli, Alberto Bonda, 2015-03-05, This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. Implementation and deployment details are also explained in order to clarify how the tools and features currently available on existing routing platforms can be used to implement the method. This method, also called PNPM (Packet Network Performance Monitoring), has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. "Implementing Draft & Release and Draft & Review in Internet Mail", Alexey Melnikov, 2015-06-17, This document describes how draft messages intended for Draft & Release and Draft & Review environments can be represented in Internet Email. "A Yang Data Model for WSON Optical Networks", Young Lee, Dhruv Dhody, Aihua Guo, Victor Lopezalvarez, Daniel King, 2015-07-01, This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in wavelength switched optical networks (WSONs). "Kerberos Service Discovery using DNS", Nathaniel McCallum, 2015-03-05, This document proposes defines a new mechanism for discovering Kerberos services using DNS. This new mechanism extends the mechanism already defined in Kerberos V5 [RFC4120] and has four goals. First, reduce the number of DNS queries required to discover a Kerberos KDC. Second, provide DNS administrators more control over client behavior. Third, provide support for discovery of the MS- KKDCP transport. Fourth, define a discovery procedure for Kerberos password services. "TURN by name: an extension to TURN for contacting an endpoint by its DNS name.", Benjamin Schwartz, Justin Uberti, 2015-03-05, When tunneling traffic through TURN, a client may sometimes desire to contact a remote endpoint that it knows by its DNS name, not its IP address. This document describes an extension to TURN that allows such a client to contact a named endpoint. "Benchmarking Methodology for IPv6 Transition Technologies", Marius, 2015-07-02, 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. The methodology also includes a tentative metric for benchmarking scalability. "DTLS as Subtransport protocol", Christian Huitema, Eric Rescorla, Jana, 2015-03-05, The developers of "user level" transports will benefit from a standard implementation of authentication and encryption. This can be achieved using DTLS as a sub-transport. Using DTLS enables developers to benefit from the investment in TLS, and removes the burden and the risks of re-creating similar technology. There are several requirements to ensure that DTLS is a suitable sub- transport: zero RTT setup, low overhead, and DOS prevention. The IAB SEMI workshop outlined other potential requirements: start/stop indication, and ability to accept indications from the network. The draft presents guidelines for meeting these requirements in a new version of DTLS. "YANG Data model for Segment Routing", fangwei hu, Ran Chen, Frank Feng, 2015-03-05, This document defines a YANG data model for segment routing technology. The data model covers configuration data and event notifications. "YANG Data Model for DHCPv6 Configuration", Yong Cui, Hao Wang, Linhui Sun, Ted Lemon, Ian Farrer, 2015-07-03, There has no unified method to configure DHCPv6 server ,relay and client itself, always pre-configured manually by operators. IETF netmod WG has developed a general data model for NETCONF protocol, YANG data model [RFC6020]. This document defines a YANG data model for the configuration and management of DHCPv6 server, DHCPv6 relay and DHCPv6 client. With this model, the operators can configure and manage the devices by using NETCONF. "A YANG Data Model for Flow Specification", Nan Wu, Shunwan Zhuang, 2015-03-06, This document defines a YANG data model for Flow Specification implementations. The data model includes configuration data and state data. "BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Greg Mirsky, 2015-07-06, 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. "Seamless BFD for VCCV", Vengada Govindan, Carlos Pignataro, 2015-06-30, This document extends the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV) to define Seamless BFD (S-BFD) for VCCV. This document will be extended in future to include definition of procedures for S-BFD over Tunnels. This document extends the CV values defined in RFC5885. "Flexibility of Transport Layer Protocols: Use Cases", Attila Mihaly, Lars Westberg, Robert Skog, 2015-03-06, This document argues for increasing the flexibility of the transport layer protocols to be possible to tailor the transport protocols to different needs (today and tomorrow) of different applications and access networks. We discuss various use cases to show that there is a need for transport protocol flexibility. "Framework for Component-based Transport Layer Protocol", Lars Westberg, Robert Skog, Attila Mihaly, 2015-03-06, This document proposes a component-based framework for a future transport layer protocol in order to allow fast transport protocol evolution via user space implementations, and to foster competition for cheap fit-for-the-purpose transport protocols available for all players. "CIRA IDN EPP Extension", Stuart Olmstead-Wilcox, Jacques Latour, JF Tremblay, 2015-03-06, The Canadian Internet Registration Authority (CIRA), administering the .CA country-code top-level domain, offers internationalized domain names (IDN) in French, one of Canada's official languages. CIRA's Extensible Provisioning Protocol (EPP) services have been augmented with an IDN EPP extension in order to support registrars desiring to register internationalized domains using French characters as bundled domains. This document defines the extension to the Extensible Provisioning Protocol used at CIRA to support IDN operations. "A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)", Marc Blanchet, Audric Schiltknecht, Peter Shames, 2015-03-06, This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS). "Diameter Routing Message Priority", Steve Donovan, 2015-05-26, When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document defines a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. "Standard way for Authoratitive DNS servers to refuse ANY query", Ólafur Guðmundsson, Marek Majkowski, 2015-03-06, DNS ANY query is widely abused for reflection attacks. This feature was designed to aid in debugging. As there is no good reason for applications to ever issue an ANY query this document codifies how an authoritative server can reject such queries. "Traffic Enginering for Bit Index Explicit Replication BIER-TE", Toerless Eckert, Gregory Cauchie, 2015-07-05, This document proposes an architecture for BIER-TE: Traffic Engineering for Bit Index Explicit Replication (BIER). BIER-TE shares part of its architecture with BIER as described in [I-D.wijnands-bier-architecture]. It also proposes to share the packet format with BIER. BIER-TE forwards and replicates packets like BIER based on a BitString in the packet header but it does not require an IGP. It does support traffic engineering by explicit hop-by-hop forwarding and loose hop forwarding of packets. It does support Fast ReRoute (FRR) for link and node protection and incremental deployment. Because BIER-TE like BIER operates without explicit in-network tree- building but also supports traffic engineering, it is more similar to SR than RSVP-TE. "Deprecate 3DES and RC4 in Kerberos", Benjamin Kaduk, Michiko Short, 2015-03-06, The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. "User Assigned ISO 3166-1 Alpha-2 Codes and the DNS Root Zone", Edward Lewis, 2015-03-06, The practice governing the delegation of ASCII two-letter domain names in the DNS root zone is to follow the ISO 3166-1 standard?s alpha 2 codes. This standard is maintained by the ISO 3166 Maintenance Agency. Contained within the gamut of ISO 3166-1 alpha 2 codes is a set of values designated as User Assigned. This document recommends that values designated as user assigned be reserved from delegation in the root zone. A specific range of these codes is assigned expressly for private-use. "YANG Data Model for PBB EVPN protocol", Kishore Tiruveedhula, Tapraj Singh, Ali Sajassi, Deepak Kumar, Luay Jalil, 2015-03-06, This document defines a YANG data model that can be used to configure and manage PBB EVPN. "Use Cases and Requirements for using Track in 6TiSCH Networks", Zhuo Chen, Chonggang Wang, 2015-07-05, This document further analyzes the 6TiSCH requirements related to Track through the use of examples and use cases. The goal of this document is to trigger discussions in 6TiSCH working group so that all relevant considerations are take into account when design Track reservation schemes in 6TiSCH. "Generic Event Delivery Using HTTP Push", Elio Damaggio, Brian Raymor, 2015-03-06, A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. "Possible approaches to make DAD more robust and/or efficient", Erik Nordmark, 2015-05-14, This outlines possible approaches to solve the issues around IPv6 Duplicate Address Detection robustness and/or efficiency which are specified in the "DAD issues" dradft. "TRILL: Appointed Forwarders", Donald Eastlake, Li Yizhou, Mohammed Umair, Ayan Banerjee, fangwei hu, 2015-03-06, TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders", with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFC 6325 and obsoletes RFC 6439. "Inter DC Traffic Optimization Using SUPA", Chongfeng Xie, Qiong, 2015-05-08, Data Centers may have many links between each other. Bandwidth over- provisioning sometimes is not a good solution to accommodate the traffic between DCs, especially for peak traffic. This draft analyze the use case of inter DC traffic optimization, and the applicability of SUPA for this case. "Information Model for Abstraction and Control of Transport Networks", Young Lee, Sergio Belotti, Daniele Ceccarelli, 2015-03-09, This draft provides an information model for abstraction and control of transport networks. "Simple Mail Transfer Protocol extension for relaying Metadata", Alexey Melnikov, 2015-06-17, This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby message metadata (such as Trace header fields, IMAP flags, Keying material, etc) can be transferred in separate containers similar to BDAT (RFC 3030, SMTP CHUNKING) command. This allows clean separation of transaction related state from the message itself. "Requiremnets for the extension of the MLD proxy functionality to support multiple upstream interfaces", Luis Contreras, Carlos Bernardos, 2015-03-07, The purpose of this document is to define the requirements for a MLD proxy with multiple interfaces covering a variety of applicability scenarios. "Communicating Prefix Cost to Mobile Nodes", Pete McCann, John Kaippallimalil, 2015-07-06, In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are known only to the network operator. This document provides a mechanism to communicate to the MN the cost of maintaining a given prefix at the MN's current point of attachment so that the MN can make better decisions about when to release old addresses and assign new ones. "Comparison between Segment Routing and LDP/RSVP-TE", Zhenbin Li, 2015-03-07, Segment Routing has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. This document is to compare Segment Routing with the existing LDP and RSVP-TE. Through the comparison the challenges are clarified for the Segment Routing when deploy in the existing MPLS network. "Patch Method for Constrained Application Protocol (CoAP)", Peter Van der Stok, Anuj Sehgal, 2015-07-06, The existing Constrained Application Protocol (CoAP) PUT method only allows a complete replacement of a resource. This does not permit applications to perform partial resource modifications. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing a resource is not an option. Several applications using CoAP will need to perform partial resource modifications. This proposal adds a new CoAP method, PATCH, to modify an existing CoAP resource partially. "Yang Data Model for Tunnel Policy", Zhenbin Li, Shunwan Zhuang, Gang Yan, 2015-03-08, This document defines a YANG data model that can be used to configure and manage tunnel policy. "Yang Model for L2VPN", Shunwan Zhuang, Haibo Wang, Zhenbin Li, 2015-03-08, This document defines a YANG data model that can be used to configure and manage L2VPN. Both VPWS and VPLS are supported. "DHCPv6 Extension for On Demand Mobility exposure", Danny Moses, Alper Yegin, 2015-06-17, Applications differ with respect to whether or not they need IP session continuity and/or IP address reachability. Networks providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes extensions to the DHCPv6 protocol to enable mobile hosts to indicate the required mobility service type associated with a requested IP address, and networks to indicate the type of mobility service associated with the allocated IP address in return. "Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sami Boutros, Sam Aldrin, 2015-07-06, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. "Propagation of IPv6 Neighbor Advertisement Flags in EVPN", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, 2015-07-06, The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements. "SCIM Event Notification", Phil Hunt, Morteza Ansari, Ian Glazer, 2015-03-08, The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized HTTP service. In a SCIM environment, changes to resources may be requested by multiple parties. As time goes by an interested subscriber may wish to be informed about resource state changes that are occurring at the SCIM service provider. This specification defines a hub notification service that can be used to publish and distribute events to interested registered subscribers. "Usage of IM for network topology to support TE Topology YANG Module Development", Hing-Kam Lam, Eve Varma, Paul Doolan, Nigel Davis, Bernd Zeuner, Malcolm Betts, Italo Busi, Scott Mansfield, 2015-07-03, The benefits of using a common Information Model (IM) as a foundation for deriving purpose and protocol specific interfaces, particularly for complex networking domains, has been described in draft-betts- netmod-framework-data-schema-uml. This draft describes an existing information model relevant to Network Topology and illustrates how it can be used to help ensure the consistency and completeness of the YANG data model for TE topologies solutions work in TEAS. "TE LSP Crossing Topology-Transparent Zones", Huaimo Chen, Renwei Li, Gregory Cauchie, Alvaro Retana, Ning So, Fengman Xu, Vic Liu, Mehmet Toy, Lei Liu, 2015-03-08, A topology-transparent zone is virtualized as the edges of the zone fully connected. This document presents the procedures for the establishment of Traffic Engineering (TE) LSPs crossing Topology- Transparent Zones. "Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom McGarry, 2015-07-06, The functions of the public switched telephone network (PSTN) are gradually migrating to the Internet. This is generating new requirements for many mechanisms used on 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 needs of the Internet environment and proposes a framework for Internet-based services relying on TNs. "Usecase of SFC for VCPE in the transport network", Qiao Fu, Hui Deng, Weiqiang Cheng, 2015-03-08, This document proposes a usecase of Service Function Chaining(SFC) to realize Virtual Customer Premises Equipment (VCPE) in the transport network. In this document, the concept of VCPE is introduced into the transport network to provide value-added services for the enterprise customers. The SFC is used to realize the VCPE and chains different services according to the requirement of the customers. Such architecture can provide value-added and self-defined services to the customers. In the meantime, SDN controller is utilized in the usecase to direct certain traffic flows to the VCPE. This usecase provides a practical mechanism to offer value-added and self-defined services in the transport network without complicating the CPE devices or increase OPEX and CAPEX cost. "Service Function Chain Extension Architecture", Rong Gu, Chen Li, 2015-03-08, An extended architecture in service function chain is provided including the applications to tenants, SDN controller, network function virtualized manager (NFVM) and the service function node. Auto-deployed self-service is provided by the orchestration of SDN controller and NFV manager. Besides, fundamental configurations and the realizations of the service function chaining are introduced with requirements raised. Benefitting from the Network function virtualization (NFV) and cloud technologies, SFC in virtual networks can bring convenient and elastic network to the customers with central management to the operators. "SDN Controller Requirement", Rong Gu, Chen Li, 2015-03-08, The requirements of SDN controllers including fundamental technical requirements, requirements of the SDN controller architecture and the requirements of the SDN controller functionality are provided. All these requirements raised are focused on the scalability, reliability, programmability, intercommunity, security and the network management of the SDN controller. "Filter-Based RIB Information Model", Sriganesh Kini, Susan Hares, Anoop Ghanwani, Ram (Ramki) Krishnan, Qin Wu, Dean Bogdanovic, Jeff Tantsura, Russ White, 2015-03-08, This document defines an information model I2RS Filter based RIB (Routing information Model). Filter based forwarding matches fields in the IP header plus other higher layer packet information. These matches may be ordered. Matches may contain actions which could impact forward, such as setting a nexthop. "A YANG Data Model for Protocol Independent Service Topology: SFF Forwarder", Zitao Wang, Susan Hares, Jeff Tantsura, Russ White, Qin Wu, Linda Dunbar, 2015-03-08, This document defines a YANG data model for Service Function Forward Topology. This I2RS yang data model is part of the I2RS protocol independent topology set of data models. "Secure Access Mechanism for DHCPv6", Yiu Lee, Yong Cui, ZiLong Liu, Linhui Sun, 2015-03-08, DHCPv6 [RFC3315] provides configuration parameters such as IPv6 network addresses for hosts. The unencrypted nature and use of various identifiers make its privacy and security become more vulnerable. With appropriate protection mechanisms, the privacy and security can be improved to some extent. This document specifies such a mechanism that builds a trusted relationship between DHCPv6 clients and servers before solicitation. The mechanism enables a valid client to find and access the legitimate server or reject and blacklist a rogue server. "Multi-Topology (MT) Segment in Segment Routing", Zhenbin Li, Nan Wu, 2015-03-08, Multi-Topologies (MTs) can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. This document proposes the multi-topology segment for segment routing. MRT FRR using multi-topology segment is described as the use case to explains the procedures of the forwarding plane and the control plane for multi-topology segment.. "Bandwidth-Guaranteed Segment Routing", Zhenbin Li, Nan Wu, 2015-03-08, The document proposes the bandwidth-guaranteed segment for the segment routing which can be used to provide the bandwidth-guaranteed segment routing path to satisfy the QoS requirement of the service. Accordingly the forwarding mechanisms and the procedures of the control plane are explained for the bandwidth-guaranteed segment. "Evaluation of Privacy for DNS Private Exchange", Aziz Mohaisen, Allison Mankin, 2015-07-06, The set of DNS requests that an individual makes can provide a monitor with a large amount of information about that individual. DNS Private Exchange (DPRIVE) aims to deprive this actor of this information. This document describes methods for measuring the performance of DNS privacy mechanisms, particularly it provides methods for measuring effectiveness in the face of pervasive monitoring as defined in RFC7258. The document includes example evaluations for common use cases. ""Sharp Close": Elimination of TIME-WAIT state of TCP connections", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 2015-07-01, This document describes an idea "Sharp Close" that eliminates or minimizes TIME-WAIT state of TCP connections. In the current TCP specification ([RFC0793]), there are some inappropriate or not up to date functions. Here we focus and discuss on TCP TIME-WAIT state function. TIME-WAIT is the last state of TCP connection of Active Close side node. After TCP connections are effectively closed, they move to TIME-WAIT state. After TIME-WAIT state is finished, resources of connections are released. This means that even if connections are effectively finished, resources of connections are NOT released. The TIME-WAIT state prevents from releasing them. From the viewpoints of current high-speed and high-multiplicity communication styles, it is thought that TIME-WAIT state is one of evil functions. In order to provide efficient communication that matches current styles, an idea "Sharp Close" that eliminates or minimizes TIME- WAIT state of TCP connections is proposed. "SIP Authentication using the EC-SRP5 Protocol", Fuwen liu, Minpeng Qi, Min Zuo, 2015-03-08, This document specifies the way that the elliptic curve secure remote protocol (EC-SRP) is applied to SIP authentication. SIP Client and server perform mutual authenticate by using the modern 'zero knowledge' method without disclosing the password in the process. It has low computation complexity and low bandwidth consumption due to the use of elliptical curve cryptography. This makes it more suitable for resource-constrained environments,e.g. wireless network. The security of the scheme is based on the computational intractability of the elliptic curve discrete logarithm problem. It is resilient to various kinds of attacks, including off-line dictionary attacks. "Server Endpoint Identifiers for Certificate Mode (D)TLS", Thomas Fossati, Hannes Tschofenig, 2015-07-06, This memo describes the use of Resource Directory names in CoAP Certificate Mode DTLS for the purpose of verifying the identity of a server by a client endpoint. "Processing Multiple Replies for One Request in NETCONF", Bing Liu, Guangying Zheng, Mahesh Jethanandani, Kent Watsen, 2015-07-06, This document discusses several scenarios that multiple replies for a single request are needed, with the ability to terminate the replies at any time. Such scenarios are not well supported by current NETCONF (Network Configuration) protocol. An extention at the NETCONF messaging layer is needed to fulfill the requirement. "Deterministic Networking Architecture", Norman Finn, Pascal Thubert, Michael Teener, 2015-03-09, Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data streams for real-time applications with extremely low data loss rates and maximum latency. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet streams in some or all of the relay systems (bridges or routers) along the path of the stream; 2) providing fixed paths for DetNet streams that do not rapidly change with the network topology; and 3) sequentializing, replicating, and eliminating duplicate packets at various points to ensure the availability of at least one path. The capabilities can be managed by configuration, or by manual or automatic network management. "IGP bandwidth based metric.", Juniper Networks, P. Sarkar, Hannes Gredler, 2015-03-09, This document describes a method to group multiple interfaces and assign metric to that group based on the cumulative bandwidth of all the interfaces in that group. Each link in a group takes same group metric irrespective of its own bandwidth. "Network Topology Service Framework for Carrier Network", Rachel Huang, Yang Yang, 2015-03-09, This document introduces a distributed network topology service framework for operators to collect network topologies from the physical heterogeneous network, analyses and stores the topology information, and provides the path computing and topology information inquiring ability to applications (including network applications like OSS, and third-party applications). "Single Area Border RBridge Nickname for TRILL Multilevel", Mingui Zhang, Donald Eastlake, Radia Perlman, Margaret Wasserman, Hongjun Zhai, 2015-07-05, A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, the area border RBridge uses a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. "Sleepy CoAP Nodes", Teresa Zotti, Peter Van der Stok, Esko Dijk, 2015-07-06, 6LoWPAN networks rely on application protocols like CoAP to enable RESTful communications in constrained environments. Many of these networks make use of "Sleepy Nodes": battery powered devices that switch off their (radio) interface during most of the time to conserve battery energy. As a result of this, Sleepy Nodes cannot be reached most of the time. This fact prevents using normal communication patterns as specified in the CoRE group, since the server-model is not applicable to these devices. This document discusses and specifies an architecture to support Sleepy Nodes such as battery-powered sensors in 6LoWPAN networks with the goal of guiding and stimulating the discussion on Sleepy Nodes support for CoAP in the CoRE WG. "IPFIX Information Element extension for SFC", Nagendra Kumar, Carlos Pignataro, Paul Quinn, 2015-07-06, Service Function Chaining (SFC) is an architecture that enables any operator to apply selective set of services by steering the traffic through an ordered set of service functions without any topology dependency. This document defines the required Information Elements to represent the details about service flows over any Service Function Path. "Distributed Mobility Anchoring", Anthony Chan, Jong-Hyouk Lee, Seil Jeon, 2015-07-03, This document defines the mobility management protocol solutions in the context of a distributed mobility management deployment. Such solutions consider the problem of assigning a mobility anchor and a gateway at the initiation of a flow. In addition, the mid-session switching of the mobility anchor in a distributed mobility management environment is considered. "Outbound Port 25 Blocking for Dynamic IP Addresses", Takehito Akagiri, Koji Wakamatsu, Kouji Okada, Kaoru Maeda, 2015-03-09, Outbound Port 25 Blocking has been widely used over a decade as a countermeasure against mail spams. It is the operation to filter TCP traffic which (1) the source IP addresses are dynamic IP addresses and (2) the destination port is 25. Since ordinal mail message submissions from dynamic IP addresses can be done via submission port (port number 587), operators can introduce the blocking without preventing ordinal mail message submissions. We explain current OP25B operations in this document. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2015-03-09, This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. "Terminology related to TLS and DTLS", Jens Guballa, Juergen Stoetzer-Bradler, He Bing, 2015-03-26, Purpose of this RFC is to provide a central place of all key terms as used by the various RFCs on protocols TLS and DTLS. "ChaMeLeon Version 2 (CMLv2): A multipath hybrid routing protocol", Alexandros Ladas, Nuwan Weerasinghe, Christos Politis, Olayinka Adigun, Olayinka Adigun, 2015-03-09, This document describes the ChaMeLeon Version 2 (CMLv2) routing protocol designed for Mobile Ad hoc Networks (MANETs). CMLv2 is a multi-path, hybrid routing protocol operating within a defined area denoted as the Critical Area (CA). The main concept behind CMLv2 is the adaptability of its routing mechanisms towards changes in the physical and logical state of a MANET. For autonomous communications, there is a likelihood that the network size will vary whenever more devices join or leave the network. In addition, battery depletion of lightweight mobile communication devices will stipulate another reason for changes in the network size. Hence, CMLv2 adapts its routing behavior according to changes in the network size within a pre-defined CA. For small networks, CMLv2 routes data proactively using the Optimized Link State Routing version v2 (OLSRv2) protocol whereas for larger networks it utilizes the reactive Ad hoc On-Demand Distance Vector Version 2 (AODVv2) Routing protocol. These transitions occur via the oscillation phase, which is maintained from CMLv1. CMLv2 creates multi-path routes for nodes with disjoint paths thereby increasing the reliability of the network. "Incremental Deployment of HNCP and IGPs in home networks", Steven Barth, 2015-03-09, This document describes an incremental approach towards deploying HNCP and routing protocols in home networks. Its aim is to provide a minimal, forward-compatible transitional extension to HNCP to promote testing, deployment and adoption of homenet technology while the IGP decision and standardization process is not yet finalized. "Network configuration Web API for Bandwidth Reservation", Yoshiharu Tsuzaki, Ray Aatarashi, Shigeya Suzuki, Koshiro Mitsuya, Kouji Okada, 2015-03-09, This draft introduces a framework for a dynamic bandwidth reservation via Web API for Web applications. In this document, we propose Web APIs for Web clients to request bandwidth allocation to network controllers. The network controller could be both of SDN compliant or Non-SDN compliant one. In this document, a network specification definition language is also proposed. "Effect of Ubiquitous Encryption", Kathleen Moriarty, Al Morton, 2015-07-06, Increased use of encryption will impact operations for security and network management causing a shift in how these functions are performed. In some cases, new methods to both monitor and protect data will evolve. In more drastic circumstances, the ability to monitor may be eliminated. This draft includes a collection of current security and network management functions that may be impacted by the shift to increased use of encryption. This draft does not attempt to solve these problems, but rather document the current state to assist in the development of alternate options to achieve the intended purpose of the documented practices. "Use Cases for Multiple Provisioning Domain in Homenet", 4c 69 61 6e 67, Hui Deng, 2015-07-05, This document describes the use cases of multiple provisioning domain (MPVD) in homenet. Although most residential networks nowadays are connected to a single ISP and normally subscribed to standard internet service, it is expected that much wider range of devices and services will become common in home networks. Homenet defines such home network topologies with increasing number of devices with the assumption that it requires minimum configuration by residential user. As described in the homenet architecture ([RFC7368]), multihoming and multi-service residential network will be more common in the near future. Nodes in such network may commonly have multiple interfaces or subscribe to multiple services. Potential types of PVD-aware nodes concerning interface and service specific provisioning domains are introduced in this document. Based on this, different MPVD configuration examples are given. These examples illustrate how PVD may be implemented in home network. PVDs provide independent provisioning domains for different interfaces and services, which enables robust and flexible network configuration for these networks. "Enablers for Transport Layer Protocol Evolution", Attila Mihaly, Szilveszter Nadas, 2015-03-09, In this document we collected requirements for TLP evolution. These requirements are the consequence of removing obstacles of TLP evolution. This results in a higher variety of expected TLP implementations and lower trust level in these. Confidentiality of communication and security is more and more important. Middleboxes which today are one of the obstacles of the evolution shall be taken into account and incentivized to cooperate in the future landscape. Resulting from the requirements we propose areas for further investigation. "MVPN UMH Procedure Based on Source Active A-D Route", Robert Kebler, Jeffrey Zhang, Andrew Dolganow, Jayant Kotalwar, Hassan Sipra, 2015-03-09, This document define new procedures to use Source-Active A-D routes to influence the UMH selection procedures at a downstream PE in certain deployments. These procedures allow some greater flexibility to influence the UMH selection based on more than just the unicast route to the source. "BGP Next-Hop Capabilities", Bruno Decraene, Kireeti Kompella, Wim Henderickx, 2015-07-06, RFC 5492 defines capabilities advertisement for the BGP peer. In addition, it is useful to know the capabilities of the BGP Next-Hop, in particular for forwarding plane features. RFC 5492 is not applicable because the BGP peer may be different from the BGP Next- Hop, in particular when BGP Route Reflection is used. This document defines a mechanism to advertise such BGP Next Hop Capabilities. This document defines a new BGP non-transitive attribute to carry Next-Hop Capabilities. This attribute is deleted when the BGP Next Hop is changed. This document also defines a Next-Hop capability to advertise the ability to handle the Entropy Label defined in RFC 6790. "RSVP Setup Retry - BCP", Ravi Singh, Rob Shakir, Vishnu Pavan Beeram, Tarek Saad, 2015-07-02, This document discusses the best current practices associated with the implementation of RSVP setup-retry timer. "Scenario of Intelligent Transportation System", Dapeng Liu, 2015-03-09, This document discuss the scenario of intelligent transportation system. "Use Case of Hierarchical Service Function Chaining", Dapeng Liu, Jie Cao, 2015-07-06, This document proposes use case and requirement of hierarchical service function chaining. "Additional Use-cases and Requirements for WebRTC Identity Architecture", Victoria Beltran, Emmanuel Bertin, Stephane Cazeaux, 2015-03-09, This document discusses additional use-cases and requirements for the WebRTC identity architecture proposed by the RTCWEB working group. "Reliable Transport For PIM Register States", Anish Peter, Robert Kebler, Vikram Nagarajan, 2015-07-06, This document introduces a hard-state, reliable transport for the existing PIM-SM registers states. This eliminates the needs for periodic NULL-registers and register-stop in response to each data- register or NULL-registers. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559]. "A YANG Data Model for Transferring Files", Qi Sun, Ian Farrer, 2015-03-09, This document defines a YANG data model for the transfer of files between devices. The data model includes operation data and state data. "Virtualized Network Deployment Practice", Vic Liu, wangjinzhu, 2015-03-09, In this draft, we introduce the deployment practice for virtual network by firstly bring out the consideration of virtual network implementation. Then with the VN architecture, discuss the five planes in Virtual network. Afterwards, introduce the interfaces between each planes. The Application will be add soon. "Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sami Boutros, 2015-03-09, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. "IETF Working Group Guidelines and Procedures", dcrocker, Ralph Droms, 2015-03-09, IETF activities are primarily organized into open-participation working groups (WGs). This document describes the formation, requirements, structure, and operation of IETF working groups. This includes the formal relationships and duties of participants. "Multiple BR Tunnel Endpoint Addresses", Ian Farrer, Qi Sun, 2015-07-06, As 'softwire' based approaches for providing IPv4 services to IPv6 networks "RTP Extensions for Transport-wide Congestion Control", Stefan Holmer, Magnus Flodman, Erik Sprang, 2015-03-09, This document proposes an RTP header extension and an RTCP message for use in congestion control algorithms for RTP-based media flows. It adds transport-wide packet sequence numbers and corresponding feedback message so that congestion control can be performed on a transport level at the send-side, while keeping the receiver dumb. "Problem Statement and Requirements for Emergency Notification using Web Push", Hirotaka Nakajima, 2015-03-09, The Web Push protocol provides a means of delivering the events to clients based on the registration made by the application. Also, the emergency alert notification system has been developed and deployed widely with mobile phones or smartphones, but has not deployed to Web-only devices. This document outlines various existing emergency alert notification system in other protocols and use cases with their requirements. "Dynamic Network Coding", Marie-Jose Montpetit, Vincent Roca, jonathan.detchart@isae.fr, 2015-03-09, This document presents a network coding approach that allows coding decisions to be based on the instantaneous conditions at the network nodes. It uses dynamic rates and coefficients to constantly adapt to local conditions and to allow for provider and application differentiation. "EVPN-VPWS Service Edge Gateway", Sami Boutros, Patrice Brissette, Ali Sajassi, daniel.voyer@bell.ca, John Drake, 2015-07-01, This document describes how a service node can dynamically terminate EVPN virtual private wire transport service (VPWS) from access nodes and offer Layer 2, Layer 3 and Ethernet VPN overlay services to Customer edge devices connected to the access nodes. Service nodes using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN overlay services it can offer for the terminated EVPN VPWS transport service. On an access node an operator can specify the L2 or L3 or Ethernet VPN overlay service needed by the customer edge device connected to the access node that will be transported over the EVPN- VPWS service between access node and service node. "Aggressive use of NSEC/NSEC3", Kazunori Fujiwara, Akira Kato, 2015-07-06, While DNS highly depends on cache, its cache usage of non-existence information was limited to exact matching. This draft proposes the aggressive use of a NSEC/NSEC3 resource record, which is able to express non-existence of range of names authoritatively. With this proposal, shorter latency to many of negative responses is expected as well as some level of mitigation of random sub-domain attacks (referred to as "Water Torture" attacks). It is also expected that non-existent TLD queries to Root DNS servers will decrease. "Thoughts a New Transport Encapsulation Architecture", Brian Trammell, 2015-05-07, This document explores architectural considerations for using encapsulation in support of stack evolution and new transport protocol deployment in an increasingly encrypted Internet. These architectural considerations are based on an idealized architecture where all interactions among applications, endpoints, and the path occur explicitly, with this cooperation enforced cryptographically. This idealized architecture is then lensed through the state of devices in the present Internet and how they would impair the deployability of such an architecture, in order to support an incremental deployment of this approach. "Frame Marking RTP Header Extension", Espen Berger, Suhas Nandakumar, Mo Zanaty, 2015-07-06, 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. "A Problem Statement to Motivate Work on Locale-free Unicode Identifiers", Andrew Sullivan, Asmus Freytag, 2015-03-09, Internationalization techniques that the IETF has adopted depended on some assumptions about the way characters get added to Unicode. Some of those assumptions turn out not to have been true. Discussion is necessary to determine how the IETF should respond to the new understanding of how Unicode works. "ALTO Extension: Abstract Path Vector as a Cost Mode", Greg Bernstein, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) Service has defined network and cost maps to provide basic network information, where the cost maps allow only scalar (numerical or ordinal) cost mode values. This document introduces a new cost mode called path-vector to allow ALTO clients to better distinguish cost information. This document starts with a non-normative use case called multi-flow scheduling to illustrate that ALTO cost maps without path vectors cannot provide sufficient information. This document then defines path-vector as a new cost mode. "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Pavan Beeram, Himanshu Shah, Xia Chen, Raqib Jones, Bin Wen, 2015-07-05, This document defines a YANG data model for the configuration and management of Traffic Engineering (TE) interfaces and tunnels. The model defines generic data that is reusable across multiple data and control plane protocols. The data model covers the configuration, operational state, remote procedural calls, and event notifications data for TE data. "PIM source discovery in Last-Hop-Router", Anish Peter, Robert Kebler, Vikram Nagarajan, 2015-07-06, This specification introduces a mechanism in PIM-SM [RFC4601] for the Last-Hop-Router (LHR) router to discover the stream information. Once this mechanism is available the complications of the shared tree procedures can be avoided. The document introduces a hard-state, reliable transport for the information about multicast streams active in the network. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559]. "IoT Security Bootstrapping: Survey and Design Considerations", ana.hedanping@huawei.com, Behcet Sarikaya, 2015-03-09, This document presents the importance of security bootstrapping for IoT networks, analyzes the state-of-the-art works in standard organizations and discusses what should be considered when designing the secure bootstrapping mechanism. "A YANG Data Model for Resource Reservation Protocol (RSVP)", Vishnu Pavan Beeram, Rakesh Gandhi, Xufeng Liu, Tarek Saad, Xia Chen, Raqib Jones, Bin Wen, 2015-07-05, This document defines a YANG data model for the configuration and management of RSVP Protocol. The model defines generic RSVP protocol building blocks that can be augmented and used by other RSVP extension models such as RVSP extensions to Traffic-Engineering (RSVP-TE). The model covers the RSVP protocol configuration, operational state, remote procedural calls, and event notifications data. "Authentication and Authorization for Constrained Environments Using OAuth and UMA", Hannes Tschofenig, Eve Maler, Erik Wahlstroem, Samuel Erdtman, 2015-03-09, Authentication and authorization are fundamental security features used in Internet and Web applications. Providing the same level of security functionality to the Internet of Things (IoT) environment as well is a logical enhancement and reduces the risk of unauthorized access to personal data. IoT devices, however, have limitations in terms of processing power, memory, user interface, Internet connectivity, etc. Since many use cases span Web and IoT environments and the question of "Web" vs. "IoT" can in some cases be considered a continuum, it is required to find security solutions that can accommodate the capabilities and constraints of both environments without significant compromises. Thus, an approach of adapting already standardized and deployed authentication and authorization technologies is worth examining. This document describes how the Web Authorization Protocol (OAuth) in combination with User-Managed Access (UMA) can be used for an IoT environment to bring Web-scale authorization services to the IoT world. "RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon, Tarek Saad, Nicholas Tan, Abhishek Deshmukh, Markus Jork, 2015-07-06, 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 LSPs 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. "Transport-layer Multicast Security for Low-Power and Lossy Networks (LLNs)", Sandeep Kumar, Rene Struik, 2015-03-09, CoAP and 6LoWPAN are fast emerging as the de-facto protocol standards in the area of resource-constrained devices forming Low-power and Lossy Networks (LLNs). Unicast communication in such networks are secured at the transport layer using DTLS, as mandated by CoAP. For various applications, IP multicast-based group communications in such networks provide clear advantages. However, at this point, CoAP does not specify how to secure group communications in an interoperable way. This draft specifies two methods for securing CoAP-based group communication at the transport layer and targets deployment scenarios that may require group authentication, respectively source authentication. The specification leverages the fact that DTLS is already used as the mechanism of choice to secure unicast communications and allows group communications security to be implemented as an extension of DTLS record layer processing, thereby minimizing incremental implementation cost. "TRILL: Link Security", Donald Eastlake, Dacheng Zhang, 2015-07-06, The TRILL protocol supports arbitrary link technologies between TRILL switches, both point-to-point and broadcast links, and supports Ethernet links between edge TRILL switches and end stations. Communications links are constantly under attack by criminals and national intelligence agencies as discussed in RFC 7258. Link security is an important element of security in depth, particularly for links that are not entirely under the physical control of the TRILL network operator or that include device which may have been compromised. This document specifies link security recommendations for TRILL over Ethernet, PPP, and pseudowire links taking into account performance considerations. It updates RFC 6325, RFC 6361, and RFC 7173. It requires that link encryption MUST be implemented and that all TRILL data packets between links ports capable of encryption at line speed MUST default to being encrypted. [This is a early partial draft.] "Additional Use Cases for Automatic Certificate Management (ACME)", John Mattsson, Robert Skog, 2015-03-09, Contacting a CA is just one way in which a newly deployed HTTPS server can get hold of the certificate to use. This document describes additional (and common) use cases that fall into the major guiding use case for ACME as stated by [I-D.barnes-acme], "obtaining certificates for Web sites". "AODVv2 Example RFC 5444 Packets", Charles Perkins, 2015-03-09, The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. This document provides some examples of AODVv2 messages encapsulated into simple packets according to the RFC 5444 specification. "Cooperative Adaptive Cruise Control and Platooning at SDOs", Alexandre Petrescu, Jing Huang, Thierry Ernst, Rex Buddenberg, 2015-07-05, This document describes the use-cases of Cooperative Adaptive Cruise Control, and Platooning, as defined by several Standards Development Organizations such as ETSI, IEEE 1609, SAE and 3GPP. C-ACC and Platooning involve concepts of direct vehicle-to-vehicle, and device-to-device communications, which are developped by 3GPP and precursory by the METIS EU project. They are illustrated very clearly in emergency settings such as FirstNet. IP messages - instead of link-layer messages - are pertinent for C-ACC and Platooning use-cases because applications for road safety such as WAZE, iRezQ and Coyote (currently involving infrastructure) are IP messages, and proved succesful in deployments. Applications such as Sentinel are direct between vehicles but are not IP, currently. "Towards recursive virtualization and programming for network and cloud resources", Robert Szabo, Zu Qiang, Mario Kind, 2015-07-06, The introduction of Network Function Virtualization (NFV) in carrier- grade networks promises improved operations in terms of flexibility, efficiency, and manageability. NFV is an approach to combine network and compute virtualizations together. However, network and compute resource domains expose different virtualizations and programmable interfaces. In [I-D.unify-nfvrg-challenges] we argued for a joint compute and network virtualization by looking into different compute abstractions. In this document we analyze different approaches to orchestrate a service graph with transparent network functions into a commodity data center. We show that a recursive compute and network joint virtualization and programming has clear advantages compared to other approaches with separated control between compute and network resources. The discussion of the problems and the proposed solution is generic for any data center use case; however, we use NFV as an example. "OSPF TE Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, Alvaro Retana, So Ning, Fengman Xu, Vic Liu, Mehmet Toy, Lei Liu, 2015-03-09, A topology-transparent zone is virtualized as the edges of the zone fully connected. This document proposes extensions to OSPF protocols to support Traffic Engineering (TE) topology-transparent zone. "Increasing Maximum Window Size of TCP", Yoshifumi Nishida, Hirochika Asai, 2015-03-09, This document proposes to increase the current max window size allowed in TCP. It describes the current logic that limits the max window size and provides a rationale to relax the limitation as well as the negotiation mechanism to enable this feature safely. "Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems", Marek Hajduczenia, Steve Burroughs, Edwin Mallette, 2015-03-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems (CM), Cable Modem Termination Systems (CMTS), DOCSIS Provisioning of EPON (DPoE) virtual Cable Modems (vCM), and DPoE Systems. This memo obsoletes RFC 4639. RFC 4639 DOCSIS Cable Device MIB December 2006 "CoAP Protocol Negotiation", Bill Silverajan, 2015-03-09, CoAP has been standardised as an application level REST-based protocol. This document introduces a way for CoAP clients and servers to interact with resources by agreeing upon alternate locations as well as transport and protocol configurations. "TLS over HTTP", Christian Huitema, 2015-03-09, We observe that attacks against HTTPS are getting more and more popular. The attacks typically exploit weaknesses in PKI certificate verification software. These weaknesses allow a third party to insert itself as a Man-In-The-Middle in a TLS connection, accessing the content of messages that were previously encrypted and in some case changing these messages. TLS over HTTP allows clients and servers to carry a TLS conversation on top of HTTP, and thus bypass the man-in-the-middle attackers. Different deployment models are possible, e.g., HTTP over TLS over HTTP, application-layer-protocol over TLS over HTTP, or HTTP over TLS over HTTP over TLS. The proposed solution allows for reuse of the existing TLS implementation, thus minimizing the development costs and risks. It includes an optional obfuscation layer, to maximize the likelihood of working unnoticed by firewalls and other MITM boxes. "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Al Morton, Lianshu Zheng, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, 2015-07-03, 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. "Current Hostname Practice Considered Harmful", Christian Huitema, Dave Thaler, 2015-03-09, Giving a hostname to your computer and publishing it as you roam from network to hot spot is the Internet equivalent of walking around with a name tag affixed to your lapel. The practice can significantly compromise your privacy, and should stop. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document studies another possible remedy, which is to replace the static hostnames by frequently changing randomized values. This idea obviously needs more work. "YANG Data Model for RFC 7210 Key Table", Helen Chen, 2015-03-09, This document defines a YANG data model to describe the key table defined in RFC 7210. The data model defined in this document augments the existing key-chain model with additional key attributes specified in RFC 7210. "Session Description Protocol (SDP) WebSocket Connection URI Attribute", Ram R, Gonzalo Salgueiro, 2015-03-09, 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. "LSP-Ping Mechanisms for EVPN and PBB-EVPN", Parag Jain, Sami Boutros, Samer Salam, 2015-07-06, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data-plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. "Improvements to ICE Candidate Nomination", Justin Uberti, Jonathan Lennox, 2015-03-09, This document makes recommendations for simplifying and improving the procedures for candidate nomination in Interactive Connectivity Establishment (ICE). "Services Function Chaining Traceroute", Reinaldo Penno, Paul Quinn, Carlos Pignataro, Danny Zhou, 2015-03-23, This document defines a protocol that checks the liveness and report the service-hops of a service path. . "Test result analysis of IPv6 Neighbor Discovery in a simple Wireless network", Ankur Sood, 2015-03-09, IPv6 WG is looking into various Neighbor Discovery (ND) optimization techniques. This document describes several test cases and test results on IPv6 ND number of messages, power usages using simple WiFi configuration and wireless phones as hosts. "BGP/MPLS IP VPN Data Center Interconnect", Luyuan Fang, Luis Contreras, daniel.voyer@bell.ca, 2015-03-09, This document discusses two categories of inter-connections of BGP/MPLS IP VPN and Data Center (DC) overlay networks. In the first category, DC overlay virtual network is built with BGP/MPLS IP VPN (IP VPN) technologies, the inter-connection of IP VPN in the DC to IP VPN in the WAN enables end-to-end IP VPN connectivity. In the second category, DC overlay network uses non IP VPN overlay technologies, the inter-connection of any overlay virtual network in the DC to IP VPN in the WAN provides end user connectivity through stitching of different overlay technologies. "Improving Scalability of Switching Systems in Large Data Centers", Ming Zhang, Shyam Kapadia, Liqin Dong, 2015-03-09, Server virtualization has been overwhelmingly accepted especially in cloud-based data centers. Accompanied with expansion of services and technology advancements, the size of a data center has increased significantly. There could be hundreds or thousands of physical servers installed in a single large data center which implies that the number of Virtual Machines (VMs) could be in the order of millions. Effectively supporting millions of VMs with limited hardware resources, becomes a real challenge to networking vendors. This document describes a method to scale a switching system with limited hardware resources using IPv6 in large data center environments. "Automatic Assignment of BIER BFR-ids in ISIS", Jeff Tantsura, Tony Przygienda, 2015-03-09, Specification of an ISIS extension to support auto-election of BFR IDs in BIER using ISIS. "Secure Real-time Transport Protocol (SRTP) for Cloud Services", Yi Cheng, John Mattsson, Mats Naslund, 2015-03-09, In order to support use cases when two or more end-points communicate via one (or more) cloud service (e.g. virtualized cloud-based conferencing) that are not trusted to access the media content, this document describes the use of so called end-to-end (inner) and hop- by-hop (outer) cryptographic transforms within the Secure Real-time Transport Protocol (SRTP). One of the main aspects of the transforms is to make the confidentiality and message authentication independent of the RTP header. Another central aspect is to enable identification of the cryptographic contexts (keys etc.). Besides the security of the end-points, also trust assumptions regarding the cloud services are addressed. "The Harmful Consequences of Postel's Maxim", Martin Thomson, 2015-03-09, Jon Postel's famous statement in RFC 1122 of "Be liberal in what you accept, and conservative in what you send" - is a principle that has long guided the design of Internet protocols and implementations of those protocols. The posture this statement advocates might promote interoperability in the short term, but that short term advantage is outweighed by negative consequences that affect the long term maintenance of a protocol and its ecosystem. "DNS Meta-Queries resticted.", Ólafur Guðmundsson, Marek Majkowski, Joe Abley, 2015-03-09, Some DNS types have special meaning and are classified as meta queries, this includes ANY, AXFR, IXFR. These queries frequently return larger answers than queries for other types. This document defines a standard way for Authoritative-Only servers how to refuse to serve these and other similar queries, with the expectation that resolvers honor that, by not asking followup queries. "A new Designated Forwarder Election for the EVPN", satyamoh@cisco.com, Keyur Patel, Ali Sajassi, John Drake, 2015-03-09, 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 "URI Schemes for SHA-1 and SHA-256", Sean Leonard, 2015-03-09, This document registers Uniform Resource Indicator schemes for use with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and SHA-256. The purpose is to identify data streams in a simple, "drop- in" way within the URI infrastructure. "Prefix-SID extensions for BGP-LU", Hannes Gredler, 2015-03-09, The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. In most MPLS deployments the ingress of a MPLS tunnel is an IP router. Availability of MPLS forwarding stacks for host operating systems is extending the MPLS perimeter to Hypervisors and Servers. Recent Data Center designs are using an IGP-less routing paradigm based on massive ECMP multi path using external BGP. This documents outlines how Hypervisors and Servers may interact with the MPLS control- and data plane using extensions to the BGP labeled unicast protocol (BGP- LU). "MPLS / TE Model for Service Provider Networks", Joshua George, Luyuan Fang, eric.osborne@level3.com, Rob Shakir, 2015-07-06, This document defines a framework for a YANG data model for configuring and managing label switched paths, including the signaling protocols, traffic engineering, and operational aspects based on carrier and content provider operational requirements. "Subscribing to YANG datastore push updates", Alex Clemm, Alberto Prieto, Eric Voit, 2015-07-06, This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to the client per a subscription policy, without requiring additional client requests. "JavaScript Object Notation Definition (JSOND)", Daniel Oskarsson, 2015-03-09, JSOND (JSON Definition) is a simple, yet powerful, definition language for JSON text. "Operational Structure and Organization of YANG Models", Anees Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, 2015-03-09, This document presents an approach for organizing YANG models in a comprehensive structure that defines how individual models may be composed to configure and operate network infrastructure and services. The structure is itself represented as a YANG model rooted at a device, with all of the related component models logically organized in a way that is operationally intuitive. "A Profile for X.509 PKIX Resource Certificates", Geoff Huston, George Michaelson, Robert Loomans, Andrew Newton, Richard Hansen, 2015-03-09, This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. This document obsoletes RFC 6487. "OSPF Link Overload", Shraddha Hegde, P. Sarkar, Hannes Gredler, 2015-03-09, Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned by means of pseudo-wires or L2-circuits. when the devices in the underlying network go for maintenance, it is useful to divert the traffic away from the node before the maintenance is actually scheduled. Since the nodes in the underlying network are not visible to OSPF, existing stub router mechanism described in [RFC3137] cannot be used. It is useful for routers in OSPFv2 or OSPFv3 routing domain to be able to advertise a link being in overload state to indicate impending maintenance activity in the underlying network devices. This document describes the protocol extensions to disseminate link overload information in OSPFv2 and OSPFv3 protocol. "Consistent Modeling of Operational State Data in YANG", Rob Shakir, Anees Shaikh, Marcus Hines, 2015-07-06, This document proposes an approach for modeling configuration and operational state data in YANG [RFC6020] that is geared toward network management systems that require capabilities beyond those typically envisioned in a NETCONF-based management system. The document presents the requirements of such systems and proposes a modeling approach to meet these requirements, along with implications and design patterns for modeling operational state in YANG. "Internet Application Identifier Architecture", Leslie Daigle, 2015-03-09, This document outlines a general architecture for Internet applications, through the perspective of applications identifiers. It provides a survey of past approaches, drawing out common elements and highlighting common traps and roadblocks. "ISIS Link Overload", Shraddha Hegde, P. Sarkar, Hannes Gredler, 2015-03-09, Many ISIS deployments run on overlay networks provisioned by means of pseudo-wires or L2-circuits. when the devices in the underlying network go for maintenance, it is useful to divert the traffic away from the specific node(s), to some alternate paths, before the maintenance is actually scheduled. Since the nodes in the underlying network are not visible to ISIS, existing Avoidance of traffic blackhole mechanism described in [RFC3277] cannot be used. It is useful for routers in IS-IS routing domain to be able to advertise a link being in overload state to indicate impending maintenance activity in the underlying network devices. This document describes the protocol extensions to disseminate link overload information in IS-IS protocol. "Encoded Stream ID Header Extension", Peter Thatcher, 2015-03-09, This document defines a new RTP Header Extension and SDES item for an Encoded Stream ID or "ESID" which can be used for either identifying Encoded Streams or for extending RTP Payload Types. "Comprehensive Core Rules for ABNF", Sean Leonard, 2015-04-15, This document extends the base definition of ABNF (Augmented Backus- Naur Form) to include comprehensive support for certain symbols, namely those in the US-ASCII standard. "Video Codec Testing and Quality Measurement", Thomas Daede, Jack, 2015-07-06, This document describes guidelines and procedures for evaluating an internet video codec specified at the IETF. This covers subjective and objective tests, test conditions, and materials used for the test. "YANG Data Model for MPLS LDP and mLDP", Kamran Raza, Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, Reshad Rahman, Rajiv Asati, Nagendra Kumar, Jeff Tantsura, Loa Andersson, Matthew Bocci, Vishnu Pavan Beeram, Stephane Litkowski, 2015-07-06, This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP) and Multipoint LDP (mLDP). "Network Topology Service (NTS) Framework", Rachel Huang, Huaming Guo, Yang Yang, 2015-03-09, This document introduces a network topology service (NTS) framework to collect network topologies from the physical heterogeneous network, NTS analyses and stores the topology information, and provides the path computing and topology information inquiring ability to applications (including network applications like OSS, and third-party applications). "Mitigation of Privacy Concerns in DHCPv6", Tomek Mrugalski, Suresh Krishnan, 2015-03-09, There is work ongoing in the dhc working group that discusses the various identifiers used by DHCPv6 and the potential privacy implications. This draft explores several migitation techniques that could be used to address the privacy issues in DHCPv6. This draft is expected to evolve significantly over time, but the ultimate goal is to standardize mitigation techniques the DHC working group considers useful. "NAT-Traversal support for Opportunistic IPsec", Antony Antony, John Gilmore, Paul Wouters, 2015-03-09, This document specifies how to support NATed IPsec peers for use with Opportunistic IPsec. "SCIM Soft Delete", Morteza Ansari, Phil Hunt, 2015-03-09, The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized HTTP service. Among other operations, SCIM defines delete operation where upon successful completion of the call, the SCIM endpoint is supposed to delete the requested object and the object should not be available for future SCIM calls and not used in uniqueness criteria requirements. While this model is sufficient for a number of SCIM implementations, there are cases this simple definition of delete may not meet product or business requirements. For example a service provider may require a user object to continue to exist as other objects/data is linked with it or for billing purposes, etc. For example a cloud file storage mechanism may require to show basic information about who created a given file or modified one even if the user is de- provisioned from the system. "MPLS RSVP-TE MBB Label Reuse", Minjie Dai, Ebben Aries, Muhammad Chaudhry, 2015-03-09, The concept of "make-before-break (MBB)" while rerouting MPLS RSVP-TE tunnels is discussed in [RFC3209]. In the procedure that is outlined, the behavior of downstream label assignment for the new LSP (new tunnel instance) is not well defined. As a general practice, a different label is assigned by each downstream router and advertised to the upstream router in the RESV message for the new LSP; this results in a separate end-to-end data-plane path for the new LSP (with the exception of PHP LSPs or UHP LSP with explicit label on the last hop). This practice allows independent end to end LSP path data-plane verification for each tunnel instance. The consequence of this practice is that the label entry gets added/deleted in the LFIB at every non-ingress router along the LSP path during MBB. Also, the ingress router would need to update all the applications using this LSP when switching to the new tunnel instance, as the new tunnel instance uses different outgoing label. This in turn may also cause other elements of the network which are dependent on the LSP to do the update. Such network churn can be avoided/minimized if the same label can be re-used (kept intact) wherever it is affecting neither the routing functionalities nor the data path verification of each instance. In addition, whenever label is reused, the setup time for the new tunnel instance would be faster because there is no need for the transit routers along the path of the new LSP to wait for the new LFIB entry to be added. This document proposes a set of procedures to facilitate label reuse when there is a total or partial path overlap between the two tunnel instances during MBB. "Forwarding-Label support in CCN Protocol", Ravi Ravindran, Asit Chakraborti, 2015-03-09, This document motivates the need for a forwarding-label which is another name that can be used in forwarding, in addition to the mandatory name in a CCNx Interest message. Forwarding-label once inserted by a edge router can be modified en-route towards the producer. Forwarding-label can be used for several purposes such as to support routing scalability, producer mobility, multi-protocol support, or for fast forwarding. We describe its encoding format, and rules followed by a forwarder while processing it. We also illustrate its use by applying it towards producer mobility. This draft scopes the use of forwarding-label within a closed trusted domain, while the use of it by applications is not ruled out. "Filter-Based RIB Information Model", Sriganesh Kini, Susan Hares, Linda Dunbar, Anoop Ghanwani, Ram (Ramki) Krishnan, Dean Bogdanovic, Jeff Tantsura, Russ White, 2015-07-06, This document defines an information model and a data model for the I2RS Filter-based Routing Information Base (RIB) Yang model. A routing system uses the Filter-based RIBto 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. "Deterministic Networks Gap Analysis", Diego Dujovne, 2015-03-09, This document introduces and describes several conditions and use cases where the use of an IP-based layer-3 and up is required to provide a complete networking solution to deterministic networks. The contents of this work is a gap analysis to contribute to the design and development of a number of complimentary modules to provide IP-enabled networking for deterministic networks. "Network Topology Service (NTS) Framework", Rachel Huang, Huaming Guo, Yang Yang, 2015-03-09, This document introduces a network topology service (NTS) framework to collect network topologies from the physical heterogeneous network, NTS analyses and stores the topology information, and provides the path computing and topology information inquiring ability to applications (including network applications like OSS, and third-party applications). "ICN Packet Format Design Requirements", Alexander Afanasyev, Ravi Ravindran, Guoqiang Wang, Lan Wang, Beichuan Zhang, Lixia Zhang, 2015-03-29, It is a great challenge to design the right packet format for the Information-Centric Networking (ICN), because this new architecture is still in its research stage. We do not have good prediction regarding either the technology advances or the application needs may involve in next 10 years and beyond. To minimize the danger of premature constraints in the packet format design, we believe it is important to first clearly identify the design requirements, so that we can use the requirements to guide the design effort. In this document we describe our understanding of the design requirements and their tradeoffs. "Managing the Authorization to Authorize in the Lifecycle of a Constrained Device", Stefanie Gerdes, 2015-03-09, Constrained nodes are devices which are limited in terms of processing power, memory, non-volatile storage and transmission capacity. Due to these constraints, commonly used security protocols are not easily applicable. Nevertheless, an authentication and authorization solution is needed to ensure the security of these devices. During the lifecycle of a constrained device, responsibility for managing authorization policies for the constrained device may change several times. To ensure the security of the constrained devices, the authorization to authorize must be transferred to the new principal in a secure way. The Delegated CoAP Authorization Framework (DCAF) specifies how resource-constrained nodes can delegate defined authentication- and authorization-related tasks to less-constrained devices called Authorization Managers, thus limiting the hardware requirements of the security solution for the constrained devices. This document defines how DCAF can be used to manage the Authorization Manager of a constrained device and introduces a flexible authorization solution for the whole lifecycle of a constrained device. "Inner Space for all TCP Options (Kitchen Sink Draft - to be Split Up)", Bob Briscoe, 2015-03-09, This document describes an experimental redesign of TCP's extensibility mechanism. It aims to traverse most known middleboxes including connection splitters, by making it possible to tunnel all TCP options within the TCP Data. It provides a choice between in- order and out-of-order delivery for TCP options. In-order delivery is a useful new facility for options that control datastream processing. Out-of-order delivery has been the norm for TCP options until now, and is necessary for options involved with acknowledging data, otherwise flow control can deadlock. TCP's original design limits TCP option space to 40B. In the new design there is no such arbitrary limit, other than the maximum size of a segment. The TCP client can immediately start to use the extra option space optimistically from the very first SYN segment, by using a dual handshake. The dual handshake is designed to prevent a legacy server from getting confused and sending the control options to the application as user-data. The dual handshake is only one strategy - a single handshake will usually suffice once deployment is underway. In summary, the protocol should allow new TCP options to be introduced i) with minimal middlebox traversal problems; ii) with incremental deployment from legacy servers; iii) with zero handshaking delay iv) with a choice of in-order and out-of-order delivery v) without arbitrary limits on available space. "BGP-LU for HSDN Label Distribution", Luyuan Fang, Chandra R, Fabio Chiussi, Yakov Rekhter, 2015-07-06, This document describes modifications of BGP Labeled Unicast (BGP-LU) procedures for label distribution in a partitioned network. Specifically, these procedures are suitable for building the Hierarchical SDN (HSDN) control plane for the hyper-scale Data Center (DC) and cloud networks. "Video Codec Requirements", Jack, Mo Zanaty, 2015-03-09, This document provides specific requirements for an Internet video codec. These requirements address quality, bit-rate, and packet-loss robustness, as well as other desirable properties. "Operational Aspects of Proxy-ARP/ND in EVPN Networks", Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, 2015-07-06, The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. 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. "Message Encryption for Web Push", Martin Thomson, 2015-07-02, A message encryption scheme is described for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an Application Server to a User Agent. "Using Operator-defined TLVs for Agile Service Deployment", Uma Chunduri, Xiaohu Xu, Luis Contreras, Mohamed Boucadair, Luay Jalil, 2015-07-02, This document proposes a TLV within the body of the OSPF Router Information (RI) Opaque LSA, called Operator-defined Sub-TLV Container TLV. Here the term OSPF means both OSPFv2 and OSPFv3.This attribute is meant to accommodate policy-based and deployment- specific use cases. "Simple Certificate Enrolment Protocol", Peter Gutmann, Max Pritikin, Andrew Nourse, J Vilhuber, 2015-03-23, This document specifies the Simple Certificate Enrolment Protocol (SCEP), a Public Key Infrastructure (PKI) communication protocol which leverages existing technology by using CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which now enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. "Off-Path Signaling Protocol for Service Function Chaining", Mauro Femminella, Gianluca Reali, Dario Valocchi, 2015-03-23, This document illustrates a reference protocol able to discover deployed instances of Service Functions (SFs), which can be located also off-path with respect to the IP datapath between flow source and flow destination. It is an application protocol organized in two layers: signaling transport, which deal lower layer signaling transport, and signaling application, which directly interfaces with the intended SF. Discovery of SFs is a primary step to for implementing Service Function Chaining (SFC). "Fluffy: Simplified Key Exchange for Constrained Environments", Thomas Hardjono, Ned Smith, 2015-07-03, This document proposes a simplified key exchange protocol for the establishment of a symmetric key shared between two devices or entities within a constrained environment. The pair-wise key establishment is performed using the mediation of a trusted Simple Key Distribution Center (SKDC) entity. The protocol also supports the mediated distribution of a group-key among multiple devices or entities for the purposes of protecting multicast messages. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 2015-07-06, This document describes characteristics of communication between interfaces in a multi-hop ad hoc wireless network, that protocol engineers and system analysts should be aware of when designing solutions for ad hoc networks at the IP layer. "Spring Segment List ID", Ran Chen, Ting Liao, 2015-03-23, Segment Routing allows a node to steer a packet through an ordered list of instructions, called segments. The ingress node prepends a SR header to a packet containing a set of "segments". A segment can represent any instruction topological or service-based. The Segment Routing architecture can be implemented using MPLS with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels, but it has implications on label stack depth. This document describes how to decrease the depth of the label stack in order to do effective Segment Routing operation. "Increasing TCP's CWND based on Throughput", Jianjie You, 2015-03-23, With 4K technology, we can get more details compared to traditional HD screens of the same size. However, 4K content increases the demand for higher network throughput, which poses a big challenge for delivering 4K content by TCP. This document proposes a target throughput based method for increasing TCP's congestion window (cwnd). Experimental results show that the proposed method can reach the required throughput much more rapidly than traditional TCP congestion algorithms, such as Reno, Cubic. Moreover, this method prevents cwnd from increasing when cwnd reaching to the required throughput. "LISP Configuration YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Albert Cabellos-Aparicio, Fabio Maino, 2015-07-06, This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). "NSEC5, DNSSEC Authenticated Denial of Existence", Jan Vcelak, Sharon Goldberg, 2015-03-23, The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence and the NSEC3 for hashed authenticated denial of existence. The NSEC RR allows for the entire zone contents to be enumerated if a server is queried for carefully chosen domain names; N queries suffice to enumerate a zone containing N names. The NSEC3 RR adds domain-name hashing, which makes the zone enumeration harder, but not impossible. This document introduces NSEC5, which provides an cryptographically- proven mechanism that prevents zone enumeration. NSEC5 has the additional advantage of not requiring private zone-signing keys to be present on all authoritative servers for the zone. "Multiple Upstream Interface Support for IGMP/MLD Proxy", Hitoshi Asaeda, Eiichi Muramoto, Luis Contreras, 2015-07-06, This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface is selected based on the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described. "DASH and HTTP2", Herve Ruellan, 2015-03-23, This document describes possibilities for DASH to take advantage of HTTP/2 features, in particular of server push. "XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Aziz Mohaisen, 2015-03-23, This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and, besides some special instantiations, is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures withstand attacks using quantum computers. "An Identity-Based Key Management Scheme for Wireless Sensor Networks", Zhongyuan Qin, Jie Huang, Xinshuai Zhang, 2015-03-23, This document specifies an efficient identity-based key management (IBKM) scheme in wireless sensor networks (WSNs),where the nodes are resource-limited, i.e., low computing capacity, small memory, power supply limitations and price,etc. This scheme exploits the Bloom filter to authenticate the communication sensor node with storage efficiency. The security analysis shows that IBKM can prevent several attacks effectively with acceptable computation and communication overhead. "The Machine-to-Machine (M2M) Public Key Certificate Format", Warwick Ford, Yuri Poeluev, 2015-03-23, The X.509 public key certificate format is overly verbose for Internet-of-Things (IoT) constrained environments, where nodes with limited memory and networks with limited bandwidth are not uncommon. The Machine-to-Machine (M2M) certificate format is a pruned down and encoding-optimized replacement for X.509, which reuses much of the X.509 semantics but reduces certificate sizes by typically 40%. We are proposing that IETF recognize the M2M format as an optional replacement for X.509 in Internet applications including, but not limited to, TLS and DTLS. "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authentication Using M2M Certificate", Yuri Poeluev, Warwick Ford, 2015-03-23, This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of M2M certificates for a TLS/DTLS session, and specifies how to transport M2M certificates via TLS/DTLS. It also defines the registry for non-X.509 certificate types. The X.509 public key certificate format is overly verbose for Internet- of-Things (IoT) constrained environments, where nodes with limited memory and networks with limited bandwidth are not uncommon. The Machine-to-Machine (M2M) certificate format is a pruned down and encoding-optimized replacement for X.509, which reuses much of the X.509 semantics but reduces certificate sizes by typically 40%. "Terminology for Benchmarking SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2015-03-23, This document defines terminology for benchmarking an SDN Controller's performance. The terms provided in this document help to benchmark SDN controller's performance independent of the controller's supported protocols and/or network services. A mechanism for benchmarking the performance of SDN controllers is defined in the companion methodology document. These two documents provide a standard mechanism to measure and evaluate the performance of various controller implementations. "Benchmarking Methodology for SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks, 2015-03-23, This document defines the methodologies for benchmarking performance of SDN controllers. Terminology related to benchmarking SDN controller 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. "RTP Payload Format for MELPe Codec", Victor Demjanenko, David Satterlee, 2015-03-23, This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder algorithm developed by Atlanta Signal Processing (ASPI), Texas Instruments (TI), SignalCom (now Microsoft) and Thales Communications with noise preprocessor contributions from AT&T under contract with NSA/DOD as international NATO Standard STANAG 4591. All three different speech encoding rates and sample frames sizes are included. Comfort noise procedures and packet loss concealment are detailed. Also, within the document there are included necessary details for the use of MELP with SDP. "Creation of Transactional Multicast Groups", Caitlin Bestler, Robert Novack, 2015-03-23, This memo presents techniques for controlling the membership of multicast groups which are constrained to be a subset of a pre- existing multicast group, where such subset groups are only used for short duration transactions which are multicast to a subset of the larger multicast group. Further the memberships of these transactional groups is pushed by the sender rather than being pulled by the receiver. These groups could be called Transactional Subset Push Multicast Groups, but that label would be a bit long. "Transmission of IPv6 Packets over WIA-PA Networks", Heng Wang, Ping Wang, Ji Zou, Xinyu Wei, 2015-03-24, This document describes the frame format and address configuration for transmission of IPv6 packets on WIA-PA (Wireless networks for Industrial Automation-Process Automation) networks. WIA-PA is approved by IEC (the International Electrotechnical Commission) as an international standard for industrial wireless networks with the designation IEC 62601. The document also describes the protocol architecture and necessary command frames for supporting IPv6 protocol in WIA-PA networks. "Encapsulation Considerations for GUE", Tom Herbert, Lucy Yong, Osama Zia, 2015-03-26, This document provides a description of how Generic UDP Encapsulation addresses the encapsulation considerations that are described in the "Encapsulation Considerations" Internet Draft. "TLS Renegotiation Support Extension to HTTP/2", Mike Bishop, 2015-03-24, The HTTP/2 spec requires that TLS renegotiation not be employed when the negotiated application protocol is HTTP/2. This document defines an extension to HTTP/2 which permits renegotiation to be employed by peers which mutually consent to do so, while allowing peers to understand whether renegotiation is permitted before attempting it. "An Information Model for Filter Rules for Discovery and Traffic for I2RS Filter-Based RIB", Linda Dunbar, Susan Hares, 2015-03-24, This draft describes an I2RS Filter RIB information model for managing routers to steer traffic to their designated service functions or service function instances via the I2RS interface. The purpose of these filters is to guide the specific flows traversing their assigned Service Function Chains in the network. "The "vnc" URI Scheme", David, Iordan Iordanov, 2015-05-15, Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts. "Fast Reroute for Node Protection in LDP-based LSPs", Santosh Esale, Yakov Rekhter, Raveendra Torvi, Luyuan Fang, Luay Jalil, 2015-03-24, This document describes procedures to support node protection for (unicast) Label Switched Paths(LSPs) established by LDP("Label Distribution Protocol"). In order to protect a node N, the Point of Local Repair (PLR) of N must discover the Merge Points(MPTs) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing point-to-point LSPs originated from the PLR to the MPTs while bypassing the protected node N. The procedures described in this document are topology independent in a sense that they provide node protection in any topology. "JOSE Direct Compact Serialization", Phillip Hallam-Baker, 2015-03-25, An alternative serialization for JOSE signatures is presented in which the headers, signature and payload are encoded directly, without Base64 encoding. Use of this format requires the use of a binary transport that does not "Requirements for Abstraction and Control of Transport Networks", Young Lee, Sergio Belotti, Khuzema Pithewan, Daniele Ceccarelli, 2015-04-06, This draft provides a set of requirements for abstraction and control of transport networks. "HTTP/1.1: Range Responses of Indeterminate Length", rcombs, 2015-04-03, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document updates RFC 7233, Part 5 of the eight-part specification that defines the protocol referred to as "HTTP/1.1". Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. This document improves support for responding to range requests for resources of indeterminate size. "Packet-Based Paradigm For Interfaces To NSFs", Ed, 2015-03-25, In the design of interfaces to allow for the provisioning of network- based security functions (NSFs), a critical consideration is to prevent the creation of implied constraints. This draft makes the recommendation that such interfaces be designed from the paradigm of processing packets on the network. NSFs ultimately are packet-processing engines that inspect packets traversing networks, either directly or in context to sessions to which the packet is associated. "IPsec traversal in Dynamic NAT", Suram Sekhar, Jyothi Vemulapalli, Rampullaiah Batchu, 2015-03-25, NAT can be enabled on a Security Gateway by administrator at any point of time. This can be called as Dynamic NAT. The existing IKEv2 RFC does not address the scenario of NAT being enabled on a security gateway after IKEv2 negotiation. In such a scenario, traffic sent over the IPsec SA will either be dropped or does not reach the peer security gateway. This document defines a method to ensure that IPsec traffic flow seamlessly in such a scenario. "Fast Reroute for Node Protection in LDP-based LSPs", Santosh Esale, Raveendra Torvi, Luyuan Fang, Luay Jalil, 2015-07-02, This document describes procedures to support node protection for (unicast) Label Switched Paths (LSPs) established by Label Distribution Protocol (LDP). In order to protect a node N, the Point of Local Repair (PLR) of N must discover the Merge Points (MPTs) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing point-to-point LSPs originated from the PLR to the MPTs while bypassing the protected node N. The procedures described in this document are topology independent in a sense that they provide node protection in any topology. "A YANG Data Model for Flow Specification", Nan Wu, Shunwan Zhuang, 2015-03-25, This document defines a YANG data model for Flow Specification implementations. The data model includes configuration data and state data. "Fragmentation option for Generic UDP Encapsulation", Tom Herbert, Fred Templin, 2015-03-25, This specification describes a fragmentation and reassembly capability with an associated header option for Generic UDP Encapsulation. "BGP FlowSpec Outbound Route Filter", Qiandeng Liang, Hao Weiguo, Jianjie You, 2015-03-26, This document defines a new ORF-type, called the "FlowSpec-ORF". FlowSpec-ORF is applicable in the networks supporting flow specifications (FlowSpec) [RFC5575]. It can be used to filter the FlowSpec rules on demand. "Using RESTCONF with LMAP Measurement Agents", Jürgen Schönwälder, Vaibhav Bajpai, 2015-03-26, This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). "Unique and Consistent Label LDP", Nipun Chawla, Rajat Setia, Himanshu Tambakuwala, 2015-03-26, This document describes a mechanism to extend LDP control plane with path control feature, improved remote LFA support and allow easier monitoring of labelled packet flows in a LDP signaled MPLS network. The mechanism introduces a method in LDP to propagate a label for loopback address of a router such that each label identifies a LDP speaking router in the network. The method enhances the scope of unique label for loopback address of each LDP speaking router in a network from a platform or an interface level to an autonomous system. The procedures described in this mechanism apply to all LDP speaking routers running with ordered downstream unsolicited label distribution. Extending these procedures to independent or downstream on demand label distribution is a case of further study and thus beyond the scope of this document. "Multi-party Multi-Domain Trust Architecture Recommendations for SDN Deployment in Carrier Network", saurabhchattopadhya@hcl.com, Kaushik Datta, 2015-03-27, This draft analyzes implementation methodologies for addressing the security requirements of SDN adopted network architecture through Public Key Infrastructure. The draft analyzes the relevant design patterns of PKI based Trust Models to address the challenges faced during SDN Adoption. And, the draft defines the considerations for setting up a Trust Relationship Management framework suitable for PKI based SDN integrated environment. "Session Security Envelope", Robert Moskowitz, Igor Faynberg, Huilan Lu, Susan Hares, Pierpaolo Giacomin, 2015-03-29, This memo specifies the details of the Session Security Envelope (SSE). SSE is a session protocol aiming to guarantee confidentiality, integrity and authentication completely independently by the underlying context, namely network and transport layers. A single session using the SEE protocol can include a single transport session or multiple transport sessions. This mean that SSE can survive the break-down in network and transport layers or to attacks carried against them. SSE is also applicable in networks lacking in classic inter-networking and transport protocols SSE relies on modern AEAD block cipher modes of operations, a class of block cipher modes which allows, at the same time, to authenticate the message while encrypting a part of it. "SCIM Password Management Extension", Phil Hunt, Gregg Wilson, 2015-03-29, The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized services. SCIM provides extension points that enable new ResourceTypes and Schema Extensions to be defined. This specification defines a set of password and account status extensions for managing passwords and password usage (e.g. failures) and other related session data. The specification defines new ResourceTypes that enable management of passwords and account recovery functions. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", Alexey Melnikov, 2015-04-18, The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 5321. "Requirements and Design Patterns for REST Northbound API in SDN", lli, Wei Zhou, Min Luo, Wu Chou, 2015-03-30, As stated in ONF SDN Architecture WG Charter [Arc2013], in the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, network operators gain programmability, automation, and network control, enabling them to build highly scalable, flexible networks that readily adapt to changing business needs. In this architecture, the Northbound API provides interfaces to the external components where applicable. As REST architectural style has gained more popularity in implementing loosely-coupled systems, RESTful services are becoming the style of choice for SDN Northbound API and gaining increasingly importance in SDN architecture, for example, the Floodlight [Floodlight] has a Northbound API based on REST. However, despite the recent advances made on RESTful web services, there is a lack of guidelines for designing RESTful networking protocols and communication web services, especially based on the Resource-Oriented Architecture (ROA) that further refines the REST principles. Many networking protocols that claim to be REST APIs are not hypertext driven as prescribed by REST. This situation can lead to REST networking APIs that are not as scalable, extensible, maintainable, and interoperable as promised by REST. This document describes the key rules and design patterns for the SDN Northbound API in a truly RESTful manner, based on our experiences with REST API designs in general and SDN Northbound API design in particular. The rules and the design patterns illustrate the solutions to the common API problems in REST API designs, using the network virtualization API of OpenStack as an example. "MPTCP Experiences in the NorNet Testbed", Thomas Dreibholz, Simone Ferlin, ozgu@simula.no, Ahmed Elmokashfi, Ioana Livadariu, Xing Zhou, 2015-07-06, This document collects some experiences of Multi-Path TCP (MPTCP) evaluations in the NorNet testbed. "Looking Glass API", Markus Stubbig, 2015-05-12, This document introduces an application programming interface (API) to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze standardized response. The API interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format. "Encoding mailbox local-parts in the DNS", John Levine, 2015-03-31, Many applications would like to store per-mailbox information securely in the DNS. Mapping mailbox local-parts into the DNS is a difficult problem, due to the fuzzy matching that most mail systems do, and the DNS design that only does exact matching. We propose several experimental approaches that attempt to implement the required fuzzy matching through DNS queries. "DNS-SD Hybrid Proxy Implementation Advice", Tom Pusateri, 2015-04-01, This document provides advice on the implementation of a DNS Service Discovery Hybrid Proxy Server. It describes the configuration parameters at the delegating DNS server, the hybrid proxy itself, and the client. It also describes the resource records required of the delegating DNS server and the hybrid proxy. "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", Nalini Elkins, Rob, Michael Ackermann, 2015-04-01, 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. "An Identity-based Security Scheme for Wireless Sensor Networks", Zhongyuan Qin, Jie Huang, Kerong Feng, 2015-04-02, This document specifies an identity-based security scheme for wireless sensor network (WSN) on the basis of Identity-Based Encryption (IBE). Each cluster head can perform as a private key generator (PKG) in case that the sole PKG is captured, which will lead to the whole network disabled. The proposed scheme can reduce the consumption of key resources and improve the security of the WSN by dispersing PKG function. The analysis shows that the scheme can resist various attacks. "Multipath Transmission Control Protocol (MPTCP) Partial Reliability Extension", Changqiao Xu, Hui Huang, Hongke Zhang, Chunshan Xiong, Lei Zhu, 2015-04-03, This memo presents an extension to the Multipath Transmission Control Protocol (MPTCP) that allows MPTCP endpoints in which case both sender side and receiver side support this function to provide partially reliable data transmission service to the upper layer applications. In order to achieve the above goal, this memo extents MPTCP by adding two new subtypes which are expressed as "PR_CAPABLE" and "ACK_NOTIFY" and the corresponding processes are also introduced. The extension can provide the backward-compatibility with MPTCP if the new features are not available. "Advertising Per-Algorithm Label Blocks", Chris Bowers, P. Sarkar, Hannes Gredler, 2015-06-24, Segment routing uses globally-known labels to accomplish destination- based forwarding along shortest paths computed using Dijkstra's algorithm with IGP metrics. This draft discusses how to use segment routing to accomplish destination-based forwarding along paths computed using other algorithms and metrics. In particular, the draft contrasts two different options for associating labels with different algorithms for computing forwarding next-hops. "EVPN Inter-subnet Multicast Forwarding", Wen Lin, Jeffrey Zhang, John Drake, 2015-05-08, This document describes inter-subnet multicast forwarding procedures for Ethernet VPNs (EVPN). "Babel doesn't care", Juliusz Chroboczek, 2015-04-04, Where we claim that, unlike typical IGPs, the Babel routing protocol just doesn't care. "WHOIS service extension", Jitendra Lulla, 2015-04-04, This document describes a service of providing a hint score of name-ip validation by whois servers. The whois servers will receive requests to provide a hint on degree of associativity between given name and IP pairs. This service may be used to acertain that the host a client intends to communicate with is indeed the host the client expects it to be. While establishing secure sessions, this service may also be used on top of certificate validation to detect any possibility of a trusted CA's issuing a fake certificate for the server in question. "Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures", Murray Kucherawy, 2015-04-05, DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations, so that a verifier might rewind such a modification and thereby confirm that the signature still verifies against the original content. "Registries for the One-Way Active Measurement Protocol - OWAMP", Al Morton, 2015-07-06, This memo describes the registries for OWAMP - the One-Way Active Measurement Protocol. The registries allow assignment of MODE bit positions and OWAMP Command numbers. The memo also requests that IANA establish the registries for new features, called the OWAMP- Modes registry and the OWAMP Control Command Number registry. "Optimized Multipath TCP subflows using Traceflow", Kesava Krupakaran, Aravind Sridharan, Shathish Venkatesan, 2015-04-07, This document proposes a solution for optimized usage of MPTCP and its subflows. "Security considerations for the Babel routing protocol", Juliusz Chroboczek, 2015-04-07, Where we stress that the Babel routing protocol is completely insecure. "Requirements for Abstraction and Control of Transport Networks", Young Lee, Dhruv Dhody, Sergio Belotti, Khuzema Pithewan, Daniele Ceccarelli, 2015-04-08, This draft provides a set of requirements for abstraction and control of transport networks. "Trusted Linker Download Redirection (TLDR)", Bennish, 2015-04-08, This document describes an HTTP extension that allows user agents to verify downloaded data. It provides a standardised way for an HTTPS URL (assumed trustworthy) to redirect to a non-HTTPS URL and give the user agent extra information about the resulting output (e.g. a downloaded file.) Once that is retrieved, it can check whether or not the data has been modified since the trustworthy site checked it (e.g. altered during transit or as a result of the destination site having been compromised.) "Title", Phillip Hallam-Baker, 2015-04-08, DNS Publication of HTTP Strict Security and Key Pinning Declarations "Syslog Management Information Base", Hiroshi Tsunoda, Glenn Mansfield, 2015-04-08, This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog applications. "Authenticated and encrypted NSH service chains", Tirumaleswar Reddy, Prashanth Patil, Scott Fluhrer, Paul Quinn, 2015-04-09, This specification adds data origin authentication and optional encryption directly to Network Service Headers (NSH) used for Service Function Chaining. "GRE Tunnel Fragmentation", Fred Templin, 2015-04-09, GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet when the delivery packet exceeds the tunnel MTU, or when otherwise necessary. This can cause problems when unmitigated IPv4 fragemntation ensues, or when middleboxes drop IPv6 fragments unconditionally. This document proposes GRE tunnel fragmentation which avoids these pitfalls.. "HTTP SEARCH Method", Julian Reschke, Ashok Malhotra, James Snell, 2015-04-10, This specification updates the definition and semantics of the HTTP SEARCH request method previously defined by [RFC5323]. "URI Attributes for OpenPGP", Vincent Breitmoser, 2015-05-05, This specification extends OpenPGP with the URI Attribute as a new type of User Attribute. "FECFRAMEv2: Adding Sliding Encoding Window Capabilities to the FEC Framework: Problem Position", Vincent Roca, 2015-06-29, The Forward Error Correction (FEC) Framework (or FECFRAME) (RFC 6363) has been defined by the FECFRAME IETF WG to enable the use of FEC Encoding with real-time flows in a flexible manner. The original FECFRAME specification only considers the use of block FEC codes, wherein the input flow(s) is(are) segmented into a sequence of blocks and FEC encoding performed independently on a per-block basis. This document discusses an extension of FECFRAME in order to enable a sliding (potentially elastic) window encoding of the input flow(s), using convolutional FEC codes for the erasure channel, as an alternative to block FEC codes. "Gopher-II: The Next Generation Gopher WWIS", Ted Matavka, Wolfgang Faust, 2015-06-08, The Gopher protocol is over twenty years old. Changing practices and unofficial extensions have caused Gopher as currently used to differ, but remain largely compatible with, the standard established in its official governing document, *The Internet Gopher Protocol (a distributed document search and retrieval protocol)*, known as *RFC 1436*. Therefore, this document attempts to establish a contemporary specification of the Gopher communications protocol, departing as little as possible from current practice. "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Gang Chen, Weibo Li, Tina Tsou, Jing Huang, Tom Taylor, 2015-04-15, This document enumerates methods of port assignment in Carrier Grade NATs (CGNs), focused particularly on NAT64 environments. A theoretical framework of different NAT port allocation methods is described. The memo is intended to clarify and focus the port allocation discussion and propose an integrated view of the considerations for selection of the port allocation mechanism in a given deployment. "Linked Identities for OpenPGP", Vincent Breitmoser, 2015-04-24, This document introduces a URI scheme for Linked Identitites to be used in URI Attributes in OpenPGP keys compatible to [RFC4880] and [URIATTR]. A Linked Identity then links the key to a resource on the internet in a mutual and verifiable way. The assumed authorization required to publish the resource forms a limited basis of trust for the key. "Generic Event Delivery Using HTTP Push", Martin Thomson, Elio Damaggio, Brian Raymor, 2015-04-15, A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. "CoRE Application Descriptions", Klaus Hartke, 2015-06-23, The interfaces of RESTful, hypertext-driven applications consist of reusable, self-descriptive components such as Internet media types and link relation types. This document defines a template that application designers can use to describe their application's interface in a structured way so that other parties can develop interoperable clients and servers or reuse the components in their own applications. "Encapsulating IP in UDP", Xiaohu Xu, Rajiv Asati, Tom Herbert, Lucy Yong, Yiu Lee, Fan Yongbing, Iljitsch van Beijnum, 2015-04-27, Existing Softwire encapsulation technologies are not adequate for efficient load balancing of Softwire service traffic across IP networks. This document specifies additional Softwire encapsulation technology, referred to as IP-in-User Datagram Protocol (UDP), which can facilitate the load balancing of Softwire service traffic across IP networks. "Fast Handover based on Registration in advance for Proxy Mobile IPv6", Hewei Yu, Ziliang Li, 2015-04-17, This memo proposes an alternative handover scheme in Proxy Mobile IPv6(PMIPv6) by making NMAG early registering to LMA before MN attaches to NMAG. Therefore, when MN handover to NMAG, it can sends the Router Advertisement message to MN immediately, because the network-layer handoff has completed already. "Lightweight Establishment of Secure Session (LESS) on CoAP", Abhijan Bhattacharyya, Soma Bandyopadhyay, Arijit Ukil, Tulika Bose, Arpan Pal, 2015-04-17, This draft presents an experimental work proposing a lightweight secure session establishment scheme to mutually authenticate two endpoints and share the session key. It works on symmetric cryptosystem with pre-shared secret between the endpoints during provisioning. The main algorithm is proposed as a generic concept. This draft further describes how the generic concept can be modeled as simple CoAP request/response pairs. Thus the proposed scheme enables CoAP with inherent security which might be useful for object security without requiring any secure transport. Still further, this draft demonstrates how the scheme could be integrated with the record encryption mechanism of DTLS-PSK. It reuses the DTLS session parameter structure without any modification. Thus channel security for the whole application message can be provided. So the scheme is a cross-layer mechanism such that the session establishment is performed in CoAP and channel encryption is performed in the transport layer reusing only the record encryption mechanism of DTLS-PSK. The scheme uses all standard encryption libraries. The lightweight nature and performance improvement is demonstrated with some supporting comparative results. "Distributed Architecture for Customer Access to Cloud", Osama Zia, 2015-04-17, This draft describes a distributed architecture within the data center for providing customers, access to their VMs in the data center. "Yang Data Model for Multicast in MPLS/BGP IP VPNs", Yisong Liu, Feng Guo, 2015-04-19, This document defines a YANG data model that can be used to configure and manage MVPN. "DDoS Open Threat Signaling use cases", Daniel Migault, 2015-04-20, The document details use cases to mitigate DDoS attacks. These use cases are expected to illustrates involved communications to detect and mitigate DDoS attacks. It is expected that these communications will be in the future handled by the DDoS Open Threat Signaling (DOTS). These scenarios are intended to be useful to derive requirements for the design of DDoS Open threat Signaling. "An Autonomic IPv6 Addressing Scheme", Michael Behringer, 2015-04-21, This document describes a generic IPv6 addressing scheme which is suitable for autonomic nodes, where node addressing must not depend on a centrally managed scheme. It assumes a unique domain name and device name, and automatically derives a unique IPv6 address from those. The scheme allows for a flat address hierarchy as well as optionally, when required, the definition of zones which are aggregatable. This document is for discussion right now; the final addressing scheme should probably move into [I-D.behringer-anima-reference-model]. "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", Charles Perkins, Vijay Devarapalli, 2015-04-21, Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). "A YANG Data Model for basic IP and ICMP Statistics", Steve Baillargeon, 2015-04-27, This document defines a YANG data model for basic IP and ICMP statistics for monitoring IPv4 and IPv6 implementations. "DMARC Escape", Douglas Otis, 2015-06-07, DMARC assumes the From header field has the combined role of Author and Sender or that it shares the same domain as that of the Sender. Message delivery becomes unreliable and the Author role may be supplanted as services adapt to DMARC's incompatible policies affecting otherwise valid and well formed messages. This document recommends two methods to allow DMARC to be compatible with RFC5322. "Framework for Interface to Network Security Functions", Ed, Diego Lopez, Linda Dunbar, Xiaojun Zhuang, Joe Parrott, Ram (Ramki) Krishnan, Seetharama Durbha, 2015-06-08, In the design of interfaces to allow for the provisioning of network security functions (NSFs), a critical consideration is to prevent the creation of implied constraints. This document makes the recommendation that such interfaces be designed from the paradigm of processing packets and flows on the network. NSFs ultimately are packet-processing engines that inspect packets traversing networks, either directly or in context to sessions to which the packet is associated. This document serves as the framework for detailed work items for I2NSF. "An Autonomic IPv6 Addressing Scheme", Michael Behringer, 2015-06-18, This document describes a generic IPv6 addressing scheme which is suitable for autonomic nodes, where node addressing must not depend on a centrally managed scheme. It assumes a unique domain name and device name, and automatically derives a unique IPv6 address from those. The scheme allows for a flat address hierarchy as well as optionally, when required, the definition of zones which are aggregatable. "Link Relation Types for Web Services", Erik Wilde, 2015-04-22, Many resources provided on the Web are part of a sets of resources that are provided in a context that is defined and managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines two link relations that allow to represent relationships from those resources to ones that provide documentation or descriptions of the Web services. The difference between these concepts is that documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. "Carrying Binding Label/Segment-ID in PCE-based Networks.", Siva Sivabalan, Clarence Filsfils, Stefano Previdi, Jeff Tantsura, Jonathan Hardwick, Mohan Nanduri, 2015-04-23, It is possible to associate a binding label to RSVP-TE signaled Traffic Engineering Label Switching Path or binding Segment-ID (SID) to Segment Routed Traffic Engineering path. Such a binding label/SID can be used by an upstream node for steering traffic into the appropriate TE path to enforce TE policies. This document proposes an approach for reporting binding label/SID to Path Computation Element (PCE) for supporting PCE-based Traffic Engineering policies. "What is an Author of an IETF Stream Draft?", Brian Carpenter, 2015-06-13, This draft suggests guidelines for assigning authorship in IETF stream Internet-Drafts. It also discusses the related issues of acknowledgements, editors and contributors. "'Urgent' Call Indicator in the Session Initiation Protocol (SIP)", Ananda Somadder, Yogendra Agarwal, 2015-04-24, This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for calling SIP User to specify the call urgency while originating a call and for called SIP user agent to identify that call is an 'Urgent' call. "A YANG Data Model for Routing Information Protocol (RIP)", Xufeng Liu, Prateek Sarda, Vikram Choudhary, 2015-07-02, This document describes a data model for Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. "UDP Magic Numbers", Tom Herbert, Lucy Yong, 2015-04-24, This specification defines magic numbers in UDP which allow a node to determine or confirm the protocol contained in a UDP payload. This is primarily applicable for encapsulation and transport protocols encapsulated within UDP where intermediate devices, such as middle boxes, need to parse these protocols for providing service. Magic numbers can also be used to multiplex different UDP encapsulated protocols over the same UDP port. "SPAKE Pre-Authentication", Nathaniel McCallum, 2015-04-24, This document defines a new password authenticated key exchange based pre-authentication mechanism for performing Kerberos authentication. This mechanism has three goals. First, it makes Kerberos pre- authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp. Second, it increases the security of the Kerberos pre-authentication exchange by making offline brute-force attacks impossible. Third, it enables the use of secure second factor authentication without FAST by utilizing the existing trust relationship established by the shared first factor. "Internet Printing Protocol/1.1: Encoding and Transport", Michael Sweet, Ira McDonald, 2015-06-10, This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. "Internet Printing Protocol/1.1: Model and Semantics", Michael Sweet, Ira McDonald, 2015-06-10, This document is one of a set of documents, which together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.1 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, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. This document also addresses security, internationalization, and directory issues. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2", Alexey Melnikov, 2015-06-16, The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev2 servers is discussed in RFC 2244. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. "Transport Layer Security (TLS) ECDHE Keyshare Extension", Bingzheng Wu, 2015-04-26, This document defines an extension that allows a TLS client to carry Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) keyshare in ClientHello message, so as to reduce the full handshake latency of one network round-trip times (RTT). "Size-Limited Bi-directional Remote Procedure Call On Remote Direct Memory Access Transports", Chuck Lever, 2015-05-20, Recent minor versions of NFSv4 work best when ONC RPC transports can send ONC RPC transactions in both directions. This document describes conventions that enable RPC-over-RDMA version 1 transport endpoints to interoperate when operation in both directions is necessary. "Making Multipath TCP robust for stateless webservers", Christoph Paasch, Anumita Biswas, Darren Haas, 2015-04-27, This document proposes an extension to Multipath TCP that allows it to work efficiently with stateless servers. We first identify the issues around stateless connection establishment using SYN-cookies. Further, we suggest an extension to Multipath TCP to overcome these issues and discuss alternatives. "Guidelines for New Router Advertisement Options", Behcet Sarikaya, Dan Luedtke, 2015-04-28, This document defines simple rules to follow when defining new router advertisement options. "Interface to Network Security Functions Demo Outline Design", Yuming Xie, Liang Xia, Jun Wu, 2015-04-28, This document describes the outline design of an Interface to network Security Functions (I2NSF) demo, aim to enhance understanding of the I2NSF architecture and justify its feasibility. The I2NSF demo enables the interaction between I2NSF client, I2NSF controller and NSF/vNSF by using NETCONF protocol and YANG model. The advantage of it is to ensure that such demo outline design will be able to share and reuse consensually designed functions, thereby increasing interoperability. "Transport Layer Security (TLS) Client Keyshare Extension", Bingzheng Wu, 2015-05-06, This document defines an extension that allows a TLS client to carry Diffie-Hellman (DH) keyshares in ClientHello message, replacing the ClientKeyExchange message in the second round-trip, to reduce the full handshake latency to one network round-trip time (RTT). "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", John Strassner, 2015-07-05, Simplified Use of Policy Abstractions (SUPA) defines an interface to a network management function that takes high-level, possibly network-wide policies as input and creates element configuration snippets as output. SUPA addresses the needs of operators and application developers to represent multiple types of policy rules, which vary in the level of abstraction, to suit the needs of different actors. This document defines a single common extensible framework for representing different types of policy rules, in the form of a set of information model fragments, that is independent of language, protocol, repository, and the level of abstraction of the content of the policy rule. This enables a common set of concepts defined in this set of information models to be mapped into different data models that use different languages, protocols, and repositories to optimize their usage. The definition of common policy concepts also provides better interoperability by ensuring that each data model can share a set of common concepts, independent of its level of detail or the language, protocol, and/or repository that it is using. Specifically, this document defines three information models: "IMAP REPLACE Extension", Stuart Brandt, 2015-04-29, This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacment is a common operation for clients that automatically save drafts or notes as a user composes them. "Using Application Identification in Services Function Chaining Metadata", Reinaldo Penno, Benoit Claise, Christophe Fontaine, 2015-04-29, This document proposes to use the structured application information in the service function chaining metadata, and specifies a YANG model for the configuration of the application registry. "Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels", Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan, 2015-04-29, [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]. "Captive Portal ICMP Destination Unreachable", David Bird, Warren Kumari, 2015-04-30, This document defines a multi-part ICMP extension to ICMP Destination Unreachable messages to signal that a user is behind a Captive Portal. [ Editor note: The IETF is currently discussing improvements in captive portal interactions and user experience improvements. See: https://www.ietf.org/mailman/listinfo/captive-portals ] [RFC Editor: Please remove this before publication. This document is being stored in github at https://github.com/wkumari/draft-wkumari- capport-icmp-unreach . Authors gratefully accept pull requests, and keep the latest (edit buffer) versions there, so commenters can follow along at home.] "Registry Reseller Extension for the Extensible Provisioning Protocol (EPP)", Linlin Zhou, Ning Kong, Chao Qi, XiaoDong Lee, James Gould, 2015-07-02, This mapping, an extension to EPP object mappings like the EPP domain name mapping [RFC5731], to support assigning a reseller to any existing object (domain, host, contact) as well as any future objects. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of registry resellers. "Extensible Provisioning Protocol (EPP) Reseller Mapping", Linlin Zhou, Ning Kong, Chao Qi, XiaoDong Lee, James Gould, 2015-07-02, This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of reseller object stored in a shared central repository. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of resellers. "VXLAN Security Option", Yuanjiao Liu, Wenhui Li, 2015-05-19, This document introduces the security extension of the VXLAN encapsulation. "On Demand Mobility API", Alper Yegin, Kisuk Kweon, Jinsung Lee, Jungshin Park, Danny Moses, 2015-05-04, Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. "YANG Alarm Module", Stefan Vallin, Martin Bjorklund, 2015-05-04, This YANG module defines an alarm interface for network devices. It includes functions for alarm list management and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. "BFD for VXLAN", Juniper Networks, Basil, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Greg Mirsky, 2015-07-06, This document describes use of Bidirectional Forwarding Detection (BFD) protocol for VXLAN . Comments on this draft should be directed to nvo3@ietf.org, rtg-bfd@ietf.org. "OVAL and the SACM Information Model", mhansbury@mitre.org, Daniel Haynes, Juan Gonzalez, 2015-05-05, The OVAL community has spent more than ten years developing and employing the OVAL Language. During this time, the community has made a number of design decisions and learned a number of lessons that should be leveraged as next generation endpoint posture assessment is formulated. There are a number of places throughout the SACM Information Model document that could be fulfilled by portions of the OVAL Language, either in its current state or, in some cases, with modifications. Another output of the work executed under the OVAL project is a number of lessons that are applicable to the SACM work. These lessons include a clear separation of data collection and evaluation; a call to focus on ensuring both primary source vendors and third party security experts feel invited to the discussion and are empowered to leverage their unique domain knowledge; and to strive for simplicity and flexibility, where possible. Finally, the OVAL community has a set of clear recommendations with respect to which parts of OVAL should be used by SACM as a means to make best use of the efforts of those that have worked on and supported OVAL over the past ten years. Those recommendations are: o Use the OVAL System Characteristics Model as a base data model for at least one way to provide data collection. o Use the OVAL Definitions Model in parts as a base data model for both evaluation and collection guidance. o Do not use the OVAL Results Model for a data model to encode evaluation results. "MPEG Media Transport Protocol (MMTP)", Imed Bouazizi, 2015-05-05, The MPEG Media Transport Protocol (MMTP) is a transport protocol that is designed to support download, progressive download, and streaming applications simultaneously. MMTP provides a generic media streaming mode by optimizing the delivery of generic media data encapsulated according to the ISO-Base Media File Format (ISOBMFF). In the file delivery mode, MMTP supports the delivery of any type of file. MMTP may used in IP unicast or multicast delivery and supports both Forward Error Correction (FEC) and retransmissions for reliable delivery of content. "Transport Layer Security (TLS) False Start", Adam Langley, Nagendra Modadugu, Bodo Moeller, 2015-05-06, This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. "Endpoint Compliance Standard", Jessica Fitzgerald-McKay, 2015-05-06, This document describes how published standards can be used to meet SACM endpoint compliance use cases. "OSPF Prefix/Link Attributes Extension Implementation Report", Acee Lindem, 2015-05-08, This document reports the results of the OSPFv2 Prefix/Link Attributes implementation survey. The survey has seven questions related to the implementer's support of OSPFv2 Prefix/Link Attributes. After a brief summary of the results, each response is listed. This document contains responses from six implementers who completed the survey. No external means were used to verify the accuracy of the information submitted by the respondents. The respondents are considered experts on the products they reported on. Additionally, responses were omitted from implementers who indicated that they have not implemented the function yet. "H-bit Support for OSPFv2", Keyur Patel, Padma Pillay-Esnault, Manish Bhardwaj, Serpil Bayraktar, 2015-05-21, OSPFv3 [RFC5340] defines an option field for router-LSAs known as a R-bit. If the R-bit is clear, an OSPFv3 router can participate in OSPF topology distribution without acting as a forwarder to forward the transit traffic. In such cases, an OSPF router would only accept traffic intended for local delivery. This draft defines R-bit functionality for OSPFv2 defined in [RFC2328]. "YANG Data Model for VxLAN Protocol", fangwei hu, Ran Chen, Mallik Mahalingam, 2015-05-06, This document defines a YANG data model for VxLAN protocol. "Signaling NSEC record owner name nonexistence", Ólafur Guðmundsson, Filippo Valsorda, 2015-05-07, DNSSEC was to large extent designed for off-line signing. A number of new opportunities arise when on-line signing is used. In negative answers case there is no real need for the wildcard proof and the server can just state that the queried name and type do not exist in a single NSEC/NSEC3 record. But such a minimally covering NSEC record that shares the name with the query name can not set the NXDOMAIN RCODE. Still, some applications want to explicitly know if the name does exist. This document allocates a new DNS RRtype that can be used to signal nonexistence of the owner names of NSEC/NSEC3 records. "Network management of encrypted traffic", Kevin Smith, 2015-06-10, Encrypted Internet traffic may pose traffic management challenges to network operators. This document recommends approaches to help manage encrypted traffic, without breaching user privacy or security. "A YANG Data Model for Flow Specification", Nan Wu, Shunwan Zhuang, Aseem Choudhary, 2015-05-11, This document defines a YANG data model for Flow Specification implementations. The data model includes configuration data and state data. "Encrypted Content-Encoding for HTTP", Martin Thomson, 2015-07-01, This memo introduces a content-coding for HTTP that allows message payloads to be encrypted. "ACTN use-case for E2E network services in multiple vendor domain transport networks", Kwang-koog Lee, Hosong Lee, Ricard Vilata, Victor Lopezalvarez, 2015-06-07, This document provides a use-case that addresses the need for facilitating the application of virtual network abstractions and the control and management of end-to-end network services that traverse multiple vendor domain transport networks. These abstractions shall help create a virtualized environment supporting operators in viewing and controlling different vendor domains, especially for end-to-end network connectivity service for a single operator. "Transport Layer Security (TLS) Jump Start", Vlad Krasnov, 2015-05-13, This document specifies an optional behavior of TLS implementation called Jump Start. It alters the way the initial Client and Server handshake messages reach their destination, but not the protocol data, and can be implemented unilaterally. The TLS Jump Start feature leads to a latency reduction of one round trip for all handshakes (on average). "DAV Server Information Object", Michael Douglass, 2015-05-13, This specification describes a new XML object that can be retrieved from hosts to discover services, features and limits for that host or domain. "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect", Scott Hollenbeck, 2015-06-18, The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. "Yang Data Model for Internet Protocol Security (IPSec)", Khanh Tran, 2015-05-14, This document defines a YANG data model that can be used to configure and manage Internet Protocol Security (IPSec). "Lightweight Token authentication (LTA) 1.0", Sebastian Baer, Bernd Haberstumpf, 2015-05-15, This document contains a specification for a token authentication mechanism that is sufficiently resource-friendly to use it on small embedded or mobile devices. The three involved parties are a service consumer (CON) a service provider (SP) and an authentication provider (AP). The authentication provider decouples authentication and the actual service that is consumed. It also serves as anonymizer. The consumer authenticates at the authentication provider, requests one or more authorization tokens and redeems those tokens when accessing the service provider's offered services. "Hostname Capability for BGP", Daniel Walton, Dinesh Dutt, 2015-07-06, In this document, we introduce a new BGP capability that allows the advertisemnet of a BGP speaker's hostname. "UDP Overlay Transport For Network Service Header", Surendra, Lawrence Kreeger, Sumandra Majee, Walter Haeffner, Rajeev Manur, 2015-05-16, This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to implement overlay transports by not requiring additional overhead as is typical of overlay mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the overlays and realize SFCs. "Distribution of TRILL Link-State using BGP", Hao Weiguo, Donald Eastlake, 2015-05-18, 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 leverage the information for topology visibility, troubleshooting, network automation, etc. "An Email Header for Improved iMIP Interoperability", Cyrus Daboo, 2015-05-18, This document defines a new email message header to improve interoperability when the iCalendar Message-Based Interoperability Protocol (iMIP) is being used to send scheduling messages. "Vpls Best-site id", Anshu Verma, John Drake, Rodny Molina, Wen Lin, 2015-05-19, With network-based applications becoming prevalent, solutions that provide connectivity over wide area become more attractive for customers. In small-to-medium enterprise sector, Virtual Private LAN Service (VPLS), is a very useful service provider offering. It creates an emulated LAN segments fully capable of learning and forwarding Ethernet MAC addresses. Today, in VPLS implementations, within the context of a VPLS PE (VE), a single-site is selected from which all PWs are rooted. The site- election mechanism is usually hard-coded by different vendors (e.g. minimum or maximum site-id), and as such, is outside end-users control. This offers no flexibility to end-users as it forces them to define the site-id allocation scheme well in advance, or deal with the consequences of a suboptimal site-id election. Moreover, whenever the elected site-id is declared down, the traffic to and from all other sites hosted within the same VE is impacted as well. This draft defines protocol extensions to keep core-facing pseudowires (PWs) established at all times, regardless of the events taking place on the attachment-circuit (AC) segment when using the BGP-based signaling procedures. "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", Stephen Kent, Di Ma, 2015-05-19, This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is performed from the perspective of an affected INR holder. "EdDSA and Ed25519 for Transport Layer Security (TLS)", Simon Josefsson, 2015-06-08, This document introduce the public-key signature algorithm EdDSA for use in Transport Layer Security (TLS). With the previous NamedCurve and ECPointFormat assignments for the Curve25519 ECDHE key exchange mechanism, this enables use of Ed25519 in TLS. New Cipher Suites for EdDSA together with AES-GCM and ChaCha20-Poly1305 are introduced here. This is intended to work with any version of TLS and Datagram TLS. "QoE Evaluation for HTTP Adaptive Streaming", Fei Wang, Zesong Fei, 2015-05-26, This document describes a method to evaluate the Quality of Experience (QoE) of real-time video delivered over HTTP Adaptive Streaming (HAS) technology. Not only the end points but also the content providers and network operators can acquire the QoE of HAS by implementing this method. "Yang Data Model for IKE", Honglei Wang, Vijay Nagaraj, Xia Chen, 2015-05-22, This document describes a YANG data model for the IKE (Internet Key Exchange) protocol. The model covers the IKE protocol configuration, operational state, remote procedural calls, and event notifications data. "A YANG Model for Managing IPv6 Tunneling", Guangying Zheng, 2015-05-22, This document describes a data model of tunneling for managing IPv6- over-IPv4 tunneling, which is used to support the transition from IPv4-only networks to integrated IPv4-based and IPv6-based networks. "Path Detection in VXLAN Overlay Network", Junying Pang, Dapeng Liu, Dacheng Zhang, Li Yizhou, Hao Chen, David Zhou, Bojian Wang, Ruichang Gao, Yan Qiao, 2015-05-22, In VXLAN overlay networks, Operation and Management(OAM)functions are important for fault management and performance monitoring. Path Detection(PD) is one critical OAM function which is applied to monitor and/or diagnose the potential paths between two VTEPs or between two Tenant System. In addition, it can assist to identify the locations of failures on data transmission paths. This document specifies a method of PD method for VXLAN Overlay Networks by using a centralized controller. However,the method can be easily extended to support the overlay networks without a centrilized controller. It can also be generalized to other overlay technique such as NVGRE. "Intent Common Information Model", Yinben Xia, Tianran Zhou, Yali Zhang, Susan Hares, Pedro Aranda, Diego Lopez, Jon Crowcroft, Yan Zhang, 2015-05-22, Intent Common Information Model (ICIM) generalizes a unified model for expressing different layers' intent whatever role, responsibility, knowledge, etc. This document provides an information model to be inherited and expanded to construct specific intent model in different areas. According to this information model, network intent model is put forward which can satisfy users' need in different layers, such as, end-users, business developers, and network administers. "Session Identifier Option for Generic UDP Encapsulation", Tom Herbert, Lucy Yong, 2015-05-22, This specification defines the session identifier option for Generic UDP Encapsulation (GUE). This option allows an encapsulator to identify a logical session to which an encapsulated packet belongs. The session for a packet may refer to the flow or connection of an encapsulated transport protocol, and the session identifier option provides visibility into this at the encapsulation layer. Nodes may use the session identifier option to create and maintain session state for encapsulated flows, and in turn can affect packet processing on the basis of this state. "Uniform Data Fingerprint (UDF)", Phillip Hallam-Baker, 2015-05-22, This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine readable codes, word and image lists. "RFC v3 Prep Tool Description", Paul Hoffman, Joe Hildebrand, 2015-07-06, This document describes some aspects of the "prep tool" that is expected to be created when the new RFC v3 specification is deployed. This draft is just a way to keep track of the ideas; it is not (currently) expected to be published as an RFC. "DNS Naming Issues", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "DNS Name Syntax", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "DNS Resource Record Sets", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Use of the TC (Truncated) Header Bit for DNS Responses", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "DNS Resource Record TTL", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Handling DNS Zone Cuts", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Multi-homed DNS Server Reply Source Address Selection", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Issues Concerning DNS SOA Resource Records", Declan Ma, 2015-05-22, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Safely Turn Authentication Credentials Into Entropy (STACIE)", Ladar Levison, 2015-05-22, This document specifies a method for Safely Turning Authentication Credentials Into Entropy (STACIE) using an efficient Zero Knowledge Password Proof (ZKPP), and is provided as a standalone component suitable for use as a building block in other protocol development efforts. The scheme was created to fill the emerging need for a standard which allows a single low entropy password to be used for user authentication and the derivation of strong encryption keys. The design is modular, and is conservative in its use of an arbitrary one-way cryptographic hash function. The security of the scheme depends on the difficulty associated with reversing the hash function output back into the plaintext input. STACIE attempts to make discovering the plaintext input through the use of brute force more difficult by linking the amount of processing to the length of a user's plaintext password. The shorter the plaintext password the more processing time per attempt with the amount of additional, artificially required, work scaling exponentially for each character. "Hierarchical Service Chaining", David Dolson, Shunsuke Homma, Diego Lopez, Mohamed Boucadair, 2015-07-06, Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to compartmentalize a large- scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large operators. "Improving the Organizational Flexibility of the SIP Change Process.", Ben Campbell, Alissa Cooper, Barry Leiba, 2015-06-19, RFC 5727 defines several processes for the Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. "Inter DC Traffic Optimization Using SUPA", Chongfeng Xie, Qiong, 2015-05-25, Data Centers may have many links between each other. Bandwidth over- provisioning sometimes is not a good solution to accommodate the traffic between DCs, especially for peak traffic. This draft analyze the use case of inter DC traffic optimization, and the applicability of SUPA for this case. "Dynamic GRE Tunnel", Sheng Jiang, Dayong Guo, Li Xue, 2015-05-26, Generic Routing Encapsulation (GRE) is regarded as a popular encapsulation tunnel technology. When a node tries to encapsulate the user traffic in GRE, it needs the IP address of the destination node which decapsulates the GRE packets. In practice, the GRE tunnel destination IP addresses are mainly configured manually. This configuration mechanism causes efficiency issues for operators. This document proposes an approach to configure the GRE information dynamically. "Gap Analysis for Layer and Technology Independent OAM Management in the Multi-Layer Environment", Yuji Tochio, Huub van Helvoort, Liang Xia, 2015-05-26, This draft analyses the existing management plane OAM related works in different SDOs, against the key objectives of Layer Independent OAM Management (LIME), to find the gap between them. The results can be used as the guidance for further work. This gap analysis is not targeted at L0-L2 transport OAM in ITU-T, either technology specific or generic across those technologies. Rather, it is intended to leverage knowledge from that domain for the benefit of developing generic layer independent OAM management for L3-L7 (and L2.5 MPLS OAM). "Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping", James Gould, 2015-05-29, This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill the gaps to ensure that all of the EPP RFC statuses are supported in RDAP. "Yang Data Model for IPIPv4 Tunnel", Ying Liu, Adam Foldes, 2015-05-26, This document defines a YANG data model for the management of IPv4 or IPv6 over IPv4 tunnels. The data model covers configuration data, operational state data and RPC execution commands. "DNS Resource Record Sets", Declan Ma, 2015-05-27, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Use of the TC (Truncated) Header Bit for DNS Responses", Declan Ma, 2015-05-27, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "DNS Resource Record TTL", Declan Ma, 2015-05-27, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Handling DNS Zone Cuts", Declan Ma, 2015-05-27, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "Issues Concerning DNS SOA Resource Records", Declan Ma, 2015-05-27, RFC 2181 collected eight independent considerations and created a single docuement to address each of them in turn. Over the following two decades it has become clear that each of these items should be considered and evovolve in its own right, as suggested in RFC 2181. This document extracts the exact text from RFC 2181 and places it into its own track. "JWS Signing Input Options", Michael Jones, 2015-05-27, JSON Web Signature (JWS) represents the payload of a JWS as a base64url encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. Also, JWS includes a representation of the JWS Protected Header and a period ('.') character in the JWS Signature computation. While this cryptographically binds the protected Header Parameters to the integrity protected payload, some of have described use cases in which this binding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not include a representation of the JWS Protected Header and a period ('.') character in the JWS Signing Input. These options are intended to broaden the set of use cases for which the use of JWS is a good fit. "RFC2181 to Historic draft-pfrc-rfc2181-historic-issues-00 Abstract", Bill Manning, 2015-05-27, RFC 2181 is an amalgamation of eight independent components that were lumped together into a single document, ostensibly because none were of enough interest to create a standalone reference for each idea. After nearly two decades, and a number of RFCs that update portions of RFC 2181, it seems reasonable to move RFC 2181 to historic status and focus on each idea independentally. This document introduces eight standalone docuements, one for each of the ideas collected in RFC 2181 and allows for examination of each idea independently. In doing so, this document moves RFC 2181 to historic status. "SCIM HTTP SEARCH Method Extension", Phil Hunt, 2015-05-28, The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized service. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. This specification extends the SCIM Protocol to include support for HTTP SEARCH. "Deterministic networking for radio access networks", Jouni Korhonen, 2015-05-28, This document describes requirements for deterministic networking in cellular radio access and transport networks context. The requirements include time synchronization, clock distribution and ways of establishing time-sensitive streams for both Layer-2 and Layer-3 user plane traffic using IETF protocol solutions. "BLACKHOLEIXP BGP Community for Blackholing at IXPs", Thomas King, Christoph Dietzel, Gert Doering, Greg Hankins, Christian Seitz, Petr Jiran, Yordan Kritski, 2015-05-28, This document describes the use of a well-known Border Gateway Protocol (BGP) community for blackholing at Internet Exchange Points (IXP). This well-known advisory transitive BGP community, namely BLACKHOLEIXP, allows an origin AS to specify through the route server that IXPs should blackhole a specific route. "Referencing Internet-Drafts in RFCs", Paul Hoffman, 2015-05-28, RFC 2026 places restrictions on how Internet-Drafts can be referred to in RFCs. Over time, the way that the IETF community uses sometimes make RFCs inaccurate (because many drafts that are referred to are not actually "works in progress", and also make references to Internet-Drafts nearly useless to RFC readers. This document updates the one part of RFC 2026, and the one part of RFC 7322, that covers referencing Internet-Drafts. "Upload Acceleration Transport Network for Upstream Traffics", Xiaowei Qin, Ning Kong, XiaoDong Lee, 2015-05-28, Photos, videos and other upstream traffics generated by end users are rapidly increasing these days and expected to continue doing so in the future. A lot of factors, such as long round-trip-time (RTT), low robustness of delivery, and transport bottlenecks, etc., lead to low upload rate, which cause poor user experiences. This draft discusses an Upload Acceleration Transport Network(UATN) for upstream traffics that use distributed cache servers and separates the upload transaction into two parts for greater network efficiency. "Traversal Using Relays around NAT (TURN) Bandwidth Probe", Paal-Erik Martinsen, Trond Andersen, Gonzalo Salgueiro, Marc Petit-Huguenin, 2015-05-29, Performing pre-call probing to discover a reasonable value for the available bandwidth, is useful information that can be utilized by bandwidth sensitive or bandwidth intensive network devices (e.g., video encoders). The method described herein is intended to produce an initial bandwidth value. Applications using this mechanism should also employ appropriate rate adaptation techniques. In addition to bandwidth, latency and bufferbloat can also be measured. No modification is needed on the server side. "Hierarchical SFC for DC Interconnection", Ting Ao, Wu Bo, 2015-05-29, Sometimes some SFs of a SFC are provided by several DC networks. That means a SFC may cross several SFs in different DC network. How to establish such SFC that is across several DCs is what we want to state. In this document, a hierarchical SFC method is proposed. It will cover data plane, control plane for such hierarchical SFC. And it includes requirements of the SFC Gateway for every DC network that provide SF for SFC. "Decentralized Sharing", Michiel de Jong, Paul Tran-Van, 2015-05-29, This draft describes the steps and challenges of sharing documents between persons, using internet-connected servers. We investigate the situation where a document exists on a server to which the sender has access through some software application, but the recipient(s) don't. All recipient(s) do, however, have access to software applications that run on least one other server. We discuss existing and proposed methods for the sender to initiate the communication, for each recipient to become aware of the sender's intent to share a document, for each recipient to access the document directly, for the document contents to be transmitted to server(s) to which the recipient(s) have access, for the sender to make and announce changes in the document after it was initially sent, and for the recipient(s) to communicate comments and proposed changes to the document back to the sender. We also discuss how semantics of the document may be communicated, and how versioning conflicts may then in some cases be resolved programmatically. Given that users of personal servers don't all run the same compatible software on their server, the sending application needs to discover which application-level protocols are supported by the receiving application(s). "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley, 2015-05-29, This document specifies a Transport Layer Security (TLS) [RFC5246] extension for the negotiation of Token Binding protocol [TBPROTO] version and key parameters. "BGP FlowSpec Outbound Route Filter", LQD, Hao Weiguo, Jianjie You, 2015-05-31, This document defines a new ORF-type, called the "FlowSpec-ORF". FlowSpec-ORF is applicable in the networks supporting flow specifications (FlowSpec) [RFC5575]. It can be used to filter the FlowSpec rules on demand. "Using EdDSA/Ed25519 in the Internet X.509 Public Key Infrastructure", Simon Josefsson, 2015-05-30, This document specify algorithm identifiers and ASN.1 encoding formats for EdDSA/Ed25519 digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKIX) for Certificates and CRLs. "Resource Transfer in the Resource Public Key Infrastructure", Rob Austein, Randy Bush, Geoff Huston, George Michaelson, 2015-05-30, Transfer within the RPKI of actual address space and/or autonomous system number resources between two Internet registries (ISPs, RIRs, NIRs, etc.) is reasonably achievable for most useful operational needs. In this paper, we describe, at a high level, how this may be accomplished. "HTTP Secure Remote Password (SRP) Authentication Scheme", Rifaat Shekh-Yusef, Yaron Sheffer, 2015-05-31, This document defines an HTTP Authentication Scheme that is based on the Secure Remote Password (SRP) protocol. The SRP protocol is an Augmented Password Authenticated Key Exchange (PAKE) protocol suitable for authenticating users and exchanging keys over an untrusted network. "Authentication and Encryption Mechanism for DHCPv6", Yong Cui, Lishan Li, Jianping Wu, Yiu Lee, 2015-07-06, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to configure network parameters. However, due to the unsecured nature, various critical identifiers used in DHCPv6 are vulnerable to several types of attacks, particularly pervasive monitoring. This document provides a mechanism to secure DHCPv6 messages, which achieves the server authentication and encryption based on sender's certificate/public key. "Use Cases for an Interface to BGP Protocol", Keyur Patel, Russ White, Susan Hares, 2015-05-31, A network routing protocol like BGP is typically configured and analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. Interface to the Routing System's (I2RS) Programmatic interfaces provides an alternate way to control and diagnose the operation of the BGP protocol. I2RS may be used for the configuration, manipulation, analyzing or collecting the protocol data. This document describes set of use cases for which I2RS can be used for BGP protocol. It is intended to provide a base for the solution draft describing a set of interfaces to the BGP protocol. "Republishing the IPV6-MIB modules as obsolete", Bill Fenner, 2015-06-30, 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. "Location Source Parameter for the SIP Geolocation Header Field", James Winterbottom, Laura Liess, Bruno Chatras, Andrew Hutton, 2015-06-02, There are some circumstances where a geolocation header field may contain more than one location value. Knowing the identity of the node adding the location value allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the location values. "Coding Tools for a Next Generation Video Codec", Timothy Terriberry, 2015-06-02, This document proposes a number of coding tools that could be incorporated into a next-generation video codec. "3RED Model for TAPS", Jianjie You, 2015-06-02, This document defines a 3RED model to describe transport service features. Applications can make use of the 3RED model to request transport services from the TAPS by sending a request which contains the explicit 3RED requirement parameters. The purpose of this document is to enable applications to make use of various transport services without customization or re-implementation. "The Network Time Protocol Version 4 Extension Format", Vikram Choudhary, Ulrich Windl, 2015-06-04, The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field as defined in RFC 5905, is an optional field that resides at the end of the NTP header and can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document redefines NTP extension header proposed in RFC 5905 for addressing unnecessary padding issue which is required for differentiating between NTP extension and MAC data. "Interoperability Testing of the Application-Layer Traffic Optimization (ALTO) Protocol", Huaming Guo, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications, with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document provides a framework that contains data structures, configurations, and message templates, to test the functionality and interoperability of an ALTO client and an ALTO server. "Interoperability Testing of the Application-Layer Traffic Optimization (ALTO) Protocol", Huaming Guo, 2015-06-03, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications that need to choose one or more endpoints to connect to among large sets of logically equivalent ones. This document provides a collection of messages that may be used to test the functionality and interoperability of an ALTO client and an ALTO server. "Ethernet VPN Yang Model", Autumn Liu, 2015-06-03, This document defines a YANG model for Ethernet VPN support. The model includes both configuration and operation to support Ethernet VPN service and deployment. "IPv6 Hop-by-Hop Header Handling", Fred Baker, 2015-07-06, This note updates the IPv6 Specification (RFC 2460), specifically commenting on the Hop-by-Hop Options Header (section 4.3) and option format and handling (section 4.2). It also updates RFC 7045, which noted that RFC 2460 is widely violated in this respect, but merely legitimized this situation with a SHOULD. The present document tries to address the issue more fundamentally. It tries to address the issue. "'Out-Of-Band' Content Coding for HTTP", Julian Reschke, Salvatore Loreto, 2015-06-04, This document describes an Hypertext Transfer Protocol (HTTP) content coding that can be used to describe the location of a secondary resource that contans the payload. "6TiSCH requirements for DetNet", Pascal Thubert, 2015-06-11, This document builds on the 6TiSCH architecture that defines, among others, mechanisms to establish and maintain deterministic routing and scheduling in a centralized fashion. The document details dependencies on DetNet and PCE controller to express topologies and capabilities, as well as abstract state that the controller must be able to program into the network devices to enable deterministic forwarding operations. "Interoperability testing of the ALTO Protocol", Wendy Roome, 2015-06-04, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications that need to choose one or more endpoints to connect to among large sets of logically equivalent ones. This document defines a data set that may be used to test the functionality and interoperability of ALTO clients and servers. "Multicast Group Address Auto-Provisioning For NVO3 Network", Hao Weiguo, Li Yizhou, Lili Wang, 2015-06-04, This document provides dynamic underlay multicast group address provisioning mechanism for each VNI or combination of VNI and overlay multicast group address. The underlay multicast group address allocation function is provided on NVA(centralized point), NVE communicates with NVA using BGP protocol extension. "DHCPv6 Option for Configuration of 6LoWPAN Compression Contexts", Randy Turner, 2015-06-05, This document specifies a DHCPv6 option to configure hosts on a 6LoWPAN with IPv6 address compression information as required by stateful compression methods specified in RFC 6282. The option provides up to 16 prefixes that can be associated with specific instances of IPv6 address compression used in 6LoWPANs. Each prefix can be a variable length of bits, and includes a validity lifetime as well. "A Message-Oriented Extension to Multipath Transmission Control Protocol (MPTCP)", Changqiao Xu, Jiuren Qin, Hongke Zhang, Chunshan Xiong, Lei Zhu, 2015-06-05, This memo specifies a message-oriented extension for Multipath TCP (MPTCP) which aims to serve high-bandwidth and real-time applications. By introducing a message mapping to MPTCP, Message- Oriented MPTCP (MO-MPTCP) attaches some message features like boundaries, priority and dependency to bytestream. With such information, MPTCP senders can optimize their transmission. "SUPA Value Proposition", Maxim Klyus, John Strassner, 2015-07-04, The rapid growth in the variety and importance of traffic flowing over increasingly complex enterprise and service provider network architectures makes the task of network operations and management applications and deploying new services much more difficult. Simplified Use of Policy Abstractions (SUPA) defines an interface to a network management function that takes high-level, possibly network-wide policies as input and creates element configuration snippets as output. SUPA expresses policies using a generic policy information model, and outputs generic YANG data models. "EdDSA and Ed25519 for Transport Layer Security (TLS)", Simon Josefsson, 2015-06-16, This document introduce the public-key signature algorithm EdDSA for use in Transport Layer Security (TLS). By defining new SignatureAlgorithm and NamedCurve enumeration values, we describe how EdDSA and Ed25519 is used for digital signatures in the existing ECDSA cipher suites. This is intended to work with any version of TLS and Datagram TLS. "Using EdDSA in the Internet X.509 Public Key Infrastructure", Simon Josefsson, 2015-06-29, This document specify algorithm identifiers and ASN.1 encoding formats for EdDSA digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKIX) for Certificates and CRLs. Parameters for Ed25519 are defined. "Ed25519 public key algorithm for the Secure Shell (SSH) protocol", Ben Harris, 2015-06-08, This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. "Via header field parameter to indicate received realm", Christer Holmberg, Yi Jiang, 2015-06-08, This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. "YANG Data Model for QoS", Helen Chen, 2015-06-09, This document defines a YANG data model to describe quality-of- service (QoS) configurations. "Pyramid Vector Quantization for Video Coding", Jean-Marc Valin, 2015-06-09, This proposes applying pyramid vector quantization (PVQ) to video coding. "Problem Statement for Abstraction and Control of Transport Networks", Young Lee, Daniel King, Mohamed Boucadair, Ruiquan Jing, Luis Contreras, 2015-06-09, Transport networks that provide connectivity and bandwidth for customer services have typically been static, lacking flexibility, and requiring long planning times when deploying new services. Network Providers and Service Providers have embraced technologies that allow separation of data plane and control plane, distributed signaling for path setup and protection, and centralized path computation for service planning and traffic engineering. Although these technologies provide significant benefits, they do not meet the growing need for network programmability, automation, resource sharing, and service elasticity necessary to meet operators' requirements for virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-administration, multi- vendor, multi-technology networks and to operate, control, and manage these multiple networks as if a single virtualized network. Another dimension of virtual network operation is the use of common core transport network resources by multi-tenant service networks as a way of providing a virtualized infrastructure to flexibly offer new services and applications. The work effort investigating this problem space is known as Abstraction and Control of Transport Networks (ACTN). This document provides an ACTN problem description, a scope of work, and outlines the core objectives and requirements to facilitate virtual network operation. "I2RS Security Related Requirements", Susan Hares, Daniel Migault, Joel Halpern, 2015-07-03, This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. "New Safe Curves for IKEv2 Key Agreement", Yoav Nir, Simon Josefsson, 2015-07-06, This document describes the use of Curve25519 and Curve448 ("Goldilocks") for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. "EDU and Mentoring Program Merger and Expansion", Mirjam Kuehne, Nalini Elkins, 2015-06-11, Education and newcomer orientation activities have existed in the IETF in various forms from the early 1990s (if not earlier). As the IETF and the world around us evolves, we are now rethinking what types of activities are best suited for the future. A mentoring program also exists at IETF that matches newcomers with experienced IETF participants. Mentoring is confined to on-site attendees. This draft proposes a merger of the mentoring and EDU functions as well as potential new activities such as videos, webcasts, and remote participation. "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", Greg Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Juniper Networks, 2015-06-11, 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. "MPLS ICMP for BIER Payload", Jeffrey Zhang, 2015-06-30, This document specifies an optional extension to generate ICMP messages for BIER packets transported over LSPs. "Intent Distribution for Autonomic Networking", Bing Liu, Sheng Jiang, 2015-06-11, This document describes the requirements of distributing intent information in an autonomic network. Ideally, the intent may be generated/injected at an arbitrary autonomic node and be distributed among the whole autonomic domain. Then this document resolves the distribution requirements into protocol design requirements. Specifically, this document introduces a solution which is some extension based on the Anima signalling protocol (GDNP, Generic Discovery and Negotiation Protocol). "Autonomic Network Intent and Format", Zongpeng Du, Sheng Jiang, Jeff, Laurent Ciavaglia, 2015-07-06, This document describes the concept and consideration of the Autonomic Network Intent, and proposes a uniform format for the Autonomic Network Intent. "The TACACS+ Protocol", Thorsten Dahm, Andrej Ota, D. Medway Gash, David Carrel, 2015-06-12, TACACS+ provides access control for routers, network access servers and other networked computing devices via one or more centralized servers. TACACS+ provides separate authentication, authorization and accounting services. This document describes the protocol that is used by TACACS+. "Fast failure detection using peer learning in VRRP with BFD", Nitish Gupta, Aditya Dogra, Colin Docherty, 2015-06-25, This draft presents an enhanced failure detection mechanism to detect the failure of VRRP Master router on the LAN using a peer learning mode. Typically the VRRP protocol is able to perform the transparent fail-over detection within a time period of 3 seconds with default fail-over timers. Real-time protocols (voice/video/real-time transactional) require a maximum network disruption in the order of 150ms for traffic on the network. A failure detection and fail-over time of 150ms on conventionally configured VRRP protocol is extremely aggressive and may impact the reliability and performance of the network. A more efficient mechanism for real-time failure detection can be enabled in VRRP protocol by building a peer table, using a new VRRP Advert packet type. This will help in forming a mesh of BFD sessions. Once the BFD sessions are created, VRRP can receive faster notification of failures, without the overhead of increased VRRP protocol Advert messages. "YANG Direct Must Augment Extension", Vladimir Vassilev, 2015-06-12, This document introduces new YANG extension statement for assignment of must sub-statements to existing data nodes through augment without the requirement for a parent data node containing the must statement. "Yang Data Model for IPsec", Honglei Wang, Vijay Nagaraj, Xia Chen, 2015-06-15, This document describes a YANG data model for the IPsec(Internet Protocol Security) protocol. The model covers the IPsec protocol operational state and remote procedural calls. "Framework for Abstraction and Control of Transport Networks", Daniele Ceccarelli, Young Lee, 2015-06-15, Transport networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator that may be the customer of the operator that actually owns the network resources. This draft provides a framework for Abstraction and Control of Transport Networks (ACTN). "The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", david.niks@vodafone.com, Andre RameilGreen, 2015-06-15, This document specifies the SIP P-User-Location-Info P-header. This header field addresses an issue that was identified when non-3GPP access and non-trusted networks are integrated to IMS (IP Multimedia Subsystem) networks. This header field conveys the trusted network determined location information of a served user when the user is registered for IMS services via non-3GPP access networks. "Using the SDP Offer/Answer Mechanism for DTLS", Christer Holmberg, Roman Shpount, 2015-06-20, 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. "Filename:", Don Jewett, 2015-06-15, *Short* Description: This Protocol automates creation and storage of Internet Links and BackLinks, together with enhanced MetaData, by individual, independent WebSites. The MetaData is displayed to Readers in SortableTables. The information in the SortableTables will be used by Readers to decide whether to follow Links and BackLinks that they encounter in using the Web, and will speed development of Knowledge based upon Web- Information. The Categories in the Tables are guided by the interests of the Readers, and differ between WebSites hosting different topics. The Protocol is designed to be implemented on individual WebSites; it does not require a centralized server nor top-down supervision. *Longer* Description: The FL-P (ForwardLink-Protocol) provides new communication conventions by which two WebSites exchange information and MetaData to provide easy and useful means for Article-Readers to decide whether to follow a Link from one Article to the another. A *RetroLink* takes the Reader to a citED Older-Text, from a citING Newer-Text. A *ForwardLink* takes the Reader to the citING Newer- Text, from a citED Older-Text. (NOTE: The words "Older" and "Newer" apply to the *Text*, *not* to the *Article* or *WebSite*. The adjectives "Forward" and "Retro" refer to the point-of-view of the Reader *when reading* the text that contains the Link. The necessity for this new terminology is explained in the body of the proposal.) Text-specific and Article-specific MetaData are presented to the Reader in SortableTables whose organization is determined by the Reader. The Reader's choices in data-categories and sorting are saved in Cookies on the Reader's Computer. These features aid the Reader in organizing the information of the SortableTables so as to decide whether to follow a displayed Link or not. These features increase the Reader's efficiency in searching for information on the Web. ForwardLinks will significantly increase the utility of the Web for scholars, thus enhancing Knowledge creation based upon Web- Information. Additionally, ForwardLinks will *increase the value* of open-access, online archives (of both Publishers and Libraries). Such archives, will, over time, collect increasing numbers of valuable ForwardLinks that point to newer developments in a field, which is critical information for further progress. ForwardLinks are based upon "human judgments of importance". For example, ForwardLinks may well occur between two Articles that do *not* share *any* duplicate words or phrases. Such Linkages *cannot be discovered* with *present WebSearch techniques*. "Privacy-Enhanced Tokens for Authorization in ACE", Jorge Cuellar, Santiago Suppan, Henrich Poehls, 2015-06-15, This specification defines PAT, "Privacy-Enhanced-Authorization- Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a token construction procedure for client authorization in a constrained environment, similar to DCAF [I-D.gerdes-ace-dcaf- authorize]. The tokens can be also used to establish a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. "Web Cache Communication Protocol V2, Revision 1", param, Jahil, 2015-06-15, This document describes version 2 of the Cisco's 'Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. "Experimental Multipath TCP option", Olivier Bonaventure, benjamin.hesmans@uclouvain.be, Mohamed Boucadair, 2015-06-16, This document proposes a generic format for an experimental Multipath TCP option. This experimental option is expected to replace the option type that was reserved for private use in [RFC6824]. "Negotiating the Maximum Number of MPTCP Subflows", Mohamed Boucadair, Christian Jacquenet, 2015-06-16, This document specifies an experimental MPTCP option that is meant to negotiate the maximum number of subflows that can be established and maintained for a given MPTCP connection. The purpose is to minimize any possible performance degradation that can be induced by a possibly large number of establishment requests for additional subflows if the remote endpoint is not appropriateley dimensioned to handle such requests. "FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources", Giridhar Mandyam, Mike Luby, Thomas Stockhammer, 2015-06-16, The FEC FRAME Raptor code options do not currently address the case of bundled protection of multiple media types over multiple real-time transport protocol (RTP) synchronization sources (SSRC's). This document provides the FEC source and repair payload definitions that enable a single repair flow to be defined for multiple RTP flows "IPv6 over 802.11ah", Luis Vega, Ines Robles, Roberto Morabito, 2015-06-17, IEEE 802.11 is an established Wireless LAN (WLAN) technology which provides radio connectivity to a wide range of devices. The IEEE 802.11ah amendment defines a WLAN system operating at sub 1 GHz license-exempt bands designed to operate with low-rate/low-power consumption. This amendment supports large number of stations and extends the radio coverage to several hundreds of meters. This document describes how IPv6 is transported over 802.11ah using 6LoWPAN techniques. "Standard Primitives versus Transport Specific Adaptation", Timothy Carey, 2015-06-17, This draft discusses the need for a consistent messaging layer that can be used but the transport protocols as they adapt to the CoAP Request/Response layer. In addition, this draft provides comments to the TCP transport implementaton described by [I-D.tschofenig-core-coap-tcp-tls]. "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Jana, Ian Swett, 2015-07-13, QUIC (Quick UDP Internet Connection) is a new multiplexed and secure transport atop UDP, designed from the ground up and optimized for HTTP/2 semantics. While built with HTTP/2 as the primary application protocol, QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC provides multiplexing and flow control equivalent to HTTP/2, security equivalent to TLS, and connection semantics, reliability, and congestion control equivalent to TCP. "QUIC Loss Recovery And Congestion Control", Ian Swett, Jana, 2015-06-17, QUIC (Quick UDP Internet Connection) is a new multiplexed and secure transport atop UDP, designed from the ground up and optimized for HTTP/2 semantics. While built with HTTP/2 as the primary application protocol, QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC implements the spirit of known TCP loss recovery mechanisms, described in RFCs, various Internet-drafts, and also those prevalent in the Linux TCP implementation. This document describes QUIC loss recovery, and where applicable, attributes the TCP equivalent in RFCs, Internet- drafts, academic papers, and/or TCP implementations. "Generic YANG Data Model for Operations, Administration, and Maintenance (OAM) Performance Management", Zitao Wang, Qin Wu, Deepak Kumar, Tom Taylor, 2015-06-19, This document presents a YANG Data model for OAM Performance Management support. The YANG Model presented in this document extends the Generic YANG Data Model for OAM by adding loss and delay measurements to support OAM Performance Management. "Dynamic Business-Rule Implementation and Execution Framework", Michael O'Connell, 2015-07-01, This memo details the structure for implementing a process of routines or functions that govern any generic task in order to achieve compliance to predefined a technical framework. "Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane, 2015-06-21, 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. "A Minimal Set of Transport Services for TAPS Systems", Stein Gjessing, Michael Welzl, 2015-06-22, This draft will eventually recommend a minimal set of IETF Transport Services offered by end systems supporting TAPS, and give guidance on choosing among the available mechanisms and protocols. As a starting point for discussion, it currently only gives an overview of some ways to categorize the set of transport services in the first TAPS document (version 4: draft-ietf-taps-transports-04), assuming that the eventual minimal set of transport services will be based on a similar form of categorization. "TLS and DTLS Security Modules", Pascal Urien, 2015-06-22, Security and trust are very critical topics in the context of the anywhere, anytime, anything internet connectivity. TLS and DTLS are two major IETF protocols widely used to secure IP exchanges. According to COAP, DTLS is the protocol used by constraint nodes in the Internet of Things (IoT) context. In this draft we specify an ISO7816 interface for TLS and DTLS secure modules based on ISO7816 secure chips, which are today manufactured per billions every year. Secure elements are cheap secure microcontrollers whose size is about 25mm2 and whose security is ranked by evaluations typically according to Common Criteria (CC) standards. The support of TLS and DTLS is based on the EAP-TLS protocol, and the IETF draft "EAP Support in smartcard" describing EAP-TLS support for secure elements. First implementation demonstrates that such low cost security modules are realistic, with a setup time for handshake completion under the second. "Guidelines on the cryptographic algorithms, accompanying the usage of standards GOST R 34.10-2012 and GOST R 34.11-2012", Stanislav Smyshlyaev, Vladimir Popov, Evgeny Alekseev, Igor Oshkin, 2015-06-23, The usage of cryptographic algorithms, that are defined by GOST R 34.10-2012 [GOST3410-2012] and GOST R 34.11-2012 [GOST3411-2012] standards, for protection of the information is carried out, as a rule, within the cryptographic protocols based on the accompanying algorithms. This memo contains a description of the accompanying algorithms for defining the pseudorandom functions, the key derivation functions, the key agreement protocols based on the Diffie-Hellman algorithm and the keying material export algorithms. "Interoperability Testing of the ALTO Protocol", Wendy Roome, Guohai Chen, 2015-06-24, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications that need to choose one or more endpoints to connect to among large sets of logically equivalent ones. This document defines a data set that may be used to test the functionality and interoperability of ALTO clients and servers. "RPL-based Clustering Routing Protocol", Yuan-Rui Tan, 2015-06-25, The IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is one of the emerging routing standards for multi-hop Wireless Sensor Networks (WSNs). RPL is based on the construction of a Destination- Oriented Directed Acyclic Graph (DODAG), which offers a loop-free topology to route data packets. But due to the tree topology, the upper nodes in tree topology are easy to run out of energy. Moreover, the hop count and ETX are the only route metrics for which standards related to their usage in RPL are published. Due to the seriously resource-constrained character, we take nodes' residual energy into account. Here we present an RPL-based clustering scheme and detailed description of Objective Function. "Video Codec Requirements and Evaluation Methodology", Alexey Filippov, 2015-07-06, This document provides requirements for a video codec designed mainly for use over the Internet. In addition, an evaluation methodology needed for measuring the parameters (compression efficiency, computational complexity, etc.) to ensure whether the stated requirements are fulfilled or not. "MLD Security", Eric Vyncke, Enno Rey, Antonios Atlasis, 2015-06-25, The latest version of Multicast Listener Discovery protocol is defined in RFC 3810, dated back in 2004. New security research has exhibited new vulnerabilities in MLD, both remote and local attack vectors. This document describes those vulnerabilities and proposes specific mitigation techniques. "I2RS Security Requirements", Daniel Migault, Joel Halpern, 2015-06-25, This document provides security requirements for the I2RS architecture. "Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI", Eric Rosen, Keyur Patel, Gunter Van de Velde, 2015-07-06, 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 additional information used to create a tunnel and the corresponding encapsulation header, and 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 updates RFC 5512 by removing that restriction, and by specifying semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document also extends the attribute by enabling it to carry additional information needed to create the encapsulation headers additional tunnel types not mentioned in RFC 5512. Finally, this document also extends the attribute by allowing it to specify a remote tunnel endpoint address for each tunnel. "IPv6-Only for Wired Thin-Clients", Eric Vyncke, Andrew Yourtchenko, Derk-Jan Valenkamp, 2015-06-26, While IPv6-only (no IPv4 at all) is becoming an objective, there are remaining issues on this road for the wired thin clients. This document enumerates of couple of them; each with a short description, followed by a description of the issue in IPv6-only networks then some solutions. It is expected that this document will grow by collecting other roadblocks and suggestions to remove them. "Use Cases and Requirements for an Interface to Network Security Functions", Antonio Pastor, Diego Lopez, Ke Wang, Xiaojun Zhuang, Minpeng Qi, Myo Zarny, Sumandra Majee, Nicolai Leymann, Linda Dunbar, Michael Georgiades, 2015-06-26, This document describes use cases and requirements for a common interface to Network Security Functions (NSF). It considers several use cases, organized in two basic scenarios. In the access network scenario, mobile and residential users access NSF capabilities using their network service provider infrastructure. In the data center scenario customers manage NSFs hosted in the data center infrastructure. "A DANE Record and DNSSEC Authentication Chain Extension for TLS", Melinda Shore, Richard Barnes, Shumon Huque, Willem Toorop, 2015-07-06, This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. "Vectors of Trust", Justin Richer, Leif Johansson, 2015-06-26, This document defines a mechanism for describing and signaling several aspects that go into a determination of trust placed in a digital identity transaction. "When to use RFC 6553, 6554 and IPv6-in-IPv6", Ines Robles, Michael Richardson, 2015-06-27, This document states different cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases to help defining the compression of RPL routing information in LLN environments. "The Extended DDoS Open Threat Signaling Use Cases", Liang Xia, Haibin Song, 2015-06-27, This draft proposes two extended use cases which illustrate more scenarios and multiple ways of implementation within the existing DOTS work scope. One is the data mining and SDN based centralized Anti-DDoS use case, the other is the NFV based distributed DDoS mitigation use case. "Client Certificates in DANE TLSA Records", Shumon Huque, Dan James, Viktor Dukhovni, 2015-07-06, The current DNS TLSA record format [RFC6698] describes how to specify TLS server certificates or their public keys in the DNS. This document makes a narrowly focused update to RFC 6698. It describes how to additionally use the TLSA record to specify client certificates, and also the rules and considerations for using them with the TLS protocol. "EVPN auto provisioning using a controller", Sami Boutros, Rex Fernando, Ali Sajassi, Junying Pang, 2015-06-28, In some datacenter use cases, a priori knowledge of what PE/NVE to be configured for a given L2 or L3 service may not be available. This document describes how EVPN can be extended to discover what L2 or L3 services to be enabled on a given PE/NVE, based on first sign of life FSOL packets received on the PE/NVE ports. An EVPN route based on the FSOL packets will be sent to a controller to trigger a push of the related L2/L3 service configuration to be provisioned on the PE/NVE and on the switch ports. "Applicability of Generic YANG Data Model for layer Independent OAM Management", Zhuangyan, Zitao Wang, Daniel King, Qin Wu, Tom Taylor, 2015-06-28, A generic YANG data model for Operations, Administration, and Maintenance (OAM) has been defined in [GENYANGOAM], with the intention that technology-specific extensions will be developed to complete the implementation of the model. In this document, we describe the applicability of the generic YANG OAM data model to specific OAM technologies. To be concrete, we also demonstrate the usability and extensibility of the generic YANG OAM model with OAM protocols such as IP Ping, traceroute, and LSP Ping. "DHCPv6 Relay Initiated Release", Sunil Gandhewar, 2015-06-28, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is initiated by a DHCPv6 client. A DHCPv6 server can force DHCPv6 client to send RENEW or INFORMATION-REQUEST by sending a RECONFIGURE message. There may be multiple DHCPv6 network devices connected in between a DHCPv6 client and a server, each one reserving resources for the DHCPv6 client. There are no DHCPv6 messages that a relay can initiate in order to control the client binding. A DHCPv6 client may not always send a RELEASE message when it no longer needs the IPv6 address. This document specifies a way to request release to be initiated by an intermediate DHCPv6 network device, e.g. DHCPv6 relay, on behalf of DHCPv6 client. This helps to relinquish network resources sooner than the lease expiration time. "DHCP Relay Initiated Release", Sunil Gandhewar, 2015-06-28, The Dynamic Host Configuration Protocol (DHCP) is initiated by a DHCP client. A DHCP server can force DHCP client to send DHCPRENEW by sending a DHCPFORCERENEW message. There may be multiple DHCP network devices connected in between a DHCP client and a server, each one reserving resources for the DHCP client. There are no DHCP messages that a relay can initiate in order to control the client binding. A DHCP client may not always send a DHCPRELEASE message when it no longer needs the IP address. This document specifies a way to request release message to be initiated by an intermediate DHCP network device, e.g. DHCP relay, on behalf of DHCP client. This helps relinquish network resources sooner than the lease expiration time. "Use Cases for SPUD", Jianjie You, Xinpeng Wei, 2015-06-28, The purpose of SPUD is to provide a standardized layer below the transport layer, to behavior as a communication channel between the host and network devices. So when a new transport protocol is deployed, it's easy for network devices to cooperate with it. New transports could have a common encapsulation to middleboxes. On the other hand, the transport layer could also make use of the state of network devices collected by the SPUD, to improve transport performance. This document provides some exemplary use cases for SPUD, especially in stateful firewall and TCP optimization. The objective of this draft is not to cover all conceivable p2a or a2p signaling in detail. Rather, the intention is to explain the requirements in these use cases as far as it is required to complement the problem statement of the SPUD. "NFV Compute Acceleration Evaluation and APIs", Bose Perumal, Wenjing Chu, Ram (Ramki) Krishnan, 2015-06-29, Network functions are being virtualized and moved to industry standard servers. Steady growth of traffic volume requires more compute power to process the network functions. Network packet based architecture provides a lot of scope for parallel processing. Generic parallel processing can be done in common multicore platforms like GPUs, coprocessors like Intel Xeon Phi[6][7] and Intel[7]/AMD[10] multicore CPUs. In this draft to check the feasibility and to exploit this parallel processing capability, multi string matching is taken as the sample network function for URL filtering. Aho-Corasick algorithm has been made use for multi pattern matching. Implementation utilizes OpenCL [3] to support many common platforms[7][10][11]. A list of optimizations is done, the application is tested on Nvidia Tesla K10 GPUs. A common API for NFV Compute Acceleration has been proposed. "Monitoring Service KPIs using TWAMP", Srivathsa Sarangapani, Peyush Gupta, 2015-06-29, We are introducing a new method to calculate services KPIs and metrics in the network using TWAMP protocol. The services here ranging from subscriber aware services to security application, Traffic load balancing, content delivery, real time streaming and like.The KPIs discussed in this draft include Service Latency, Serviced Packets Count, Serviced Subscriber Count, Application Liveliness and Session load per Service. KPIs monitoring of these services therefore, play a vital role in optimum usage of network resources such as capacity and throughput. Once we have the attributes like service latency, the network topology can be chosen to provide better quality of experience to the end user. For different services, the attributes may vary and our design takes care of supporting different KPIs for different services model. Additionally, liveliness of application and servers can be monitored using this proposed solution. "ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)", John Mattsson, Daniel Migault, 2015-07-06, This memo defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. "PCEP Extensions for LSP scheduling with stateful PCE", Zhuangyan, Qin Wu, Dhruv Dhody, 2015-06-29, This document proposes a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage duration of a traffic service in a centralized network environment. A scheduled LSP can be setup at the its starting time and deleted after its usage duration such that LSPs for the other traffic services can take over these network resources beyond that period. "The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation with Transactions", Petr Spacek, 2015-06-29, This document specifies LDAP Control which extends the persist stage of the Content Synchronization Operation with information about LDAP transaction boundaries. This information can be used to support application-level transactions or for application-level optimizations. "Clarifications to the Dynamic Updates in the Domain Name System (DNS UPDATE) specification", Petr Spacek, 2015-06-29, This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. "Record NEXTHOP_PATH ATTIBUTE for BGP", Susan Hares, Zhenbin Li, Li Zhang, 2015-06-29, In some BGP deployments, BGP next hops may use a set or tunnels or run across converged networks such as seamless MPLS. This document describes a new optional transitive path attribute, NEXTHOP_PATH ATTRIBUTE for BGP that records the next hop path which can be used by BGP network management to monitor and manage the BGP infrastructure via management interfaces (such as I2RS). "Modular Mathematical Mesh", Phillip Hallam-Baker, 2015-06-29, The Magic Mathematical Mesh 'the Mesh' is a security infrastructure for the Internet that puts individual users in control of their security. Through large scale redundancy and replication techniques, mesh users have a high level of assurance that data stored in the mesh through a mesh gateway node will be available at a later date. The mesh does not offer confidentiality guarantees. All data in the mesh is assumed to be public. Confidential data stored in the mesh must be protected using strong encryption. The mesh provides a medium that enables the exchange of private key data but never passes private data of any form in plaintext form. The mesh enables use of end-to-end and transport security with mutual authentication in a wide range of client server and peer-peer applications. These include email, remote access and the Web. Unlike previous attempts to establish such infrastructures, the password management application supported by the mesh delivers users with an immediate benefit that does not rely on adoption by others. "Authorization for Constrained RESTful Environments", Ludwig Seitz, Goran Selander, Malisa Vucinic, 2015-06-29, This memo defines a framework for authorization in constrained-node networks, i.e. networks where some devices have severe constraints on memory, processing, power and communication bandwidth. The main goal is to offload constrained devices by providing them access control support from trusted parties that are less constrained. The approach is based on RESTful requests to dedicated access management resources, supporting different authorization schemes and communication security paradigms. "MPTCP Implementation (Challenges) Usecases", Palanivelan Appanasamy, Chetan Harsha, 2015-06-29, MPTCP Intends to address a wide range of issues, with minimal implementation tweaks. Though this works in a range of use cases, there are some use cases, where some standard implementation recommendations could help. The Purpose of this draft is to document the use cases, where there are opportunities for standard implementation recommendations. "Simplified Updates of DNS Security (DNSSEC) Trust Anchors", Warren Kumari, 2015-06-29, This document describes a simple means for automated updating of DNSSEC trust anchors. This mechanism allows the trust anchor maintainer to monitor the progress of the migration to the new trust anchor, and so predict the effect before decommissioning the existing trust anchor. It is primarily aimed at the root DNSSEC trust anchor, but should be applicable to trust anchors elsewhere in the DNS as well. [ Ed note - informal summary: One of the big issues with rolling the root key is that it is unclear who all is using RFC5011, who all has successfully fetched and installed the new key, and, most importantly, who all will die when the old key is revoked. A secondary problem is that the response sizes suddenly increase, potentially blowing the MTU limit. This document describes a method that is basically CDS, but for the root key (or any other trust anchor). Unlike the CDS record though, this record lives at a special name - by querying for this name, the recursive exposes its list of TAs to the auth server (signalling upstream) . This allows the TA maintainer to predict how many, and who all will break. It also allows the pre-publication of a key before using it, and so avoids the need to double response sizes...] [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.] [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ] "Using Curve25519 and Curve448 Public Keys in PKIX", Simon Josefsson, 2015-06-29, This document specify "named curve" object identifiers for Curve25519 and Curve448, for use as subject public keys in X.509 PKIX Certificates. "Text messaging to middlebox administrators using ICMP", Michael Welzl, Jianjie You, 2015-06-29, This document describes the use of an ICMP message to send text messages to on-path middleboxes from the endpoints. The text message is sent towards a destination but meant to be read by administrators of middleboxes along the path to the destination. The goal is to improve the user's experience with simple middlebox cooperation. "Co-operative DDoS Mitigation", Tirumaleswar Reddy, Dan Wing, Prashanth Patil, Mike Geller, Mohamed Boucadair, 2015-06-29, This document discusses mechanisms that a downstream Autonomous System (AS) can use, when it detects a potential Distributed Denial- of-Service (DDoS) attack, to request an upstream AS to perform inbound filtering in its ingress routers for traffic that the downstream AS wishes to drop. The upstream AS can then undertake appropriate actions (including, blackhole, drop, rate-limit, or add to watch list) on the suspect traffic to the downstream AS thus reducing the effectiveness of the attack. "Information Model for DDoS Open Threat Signaling (DOTS)", Tirumaleswar Reddy, Prashanth Patil, Mike Geller, Dan Wing, Sandeep Rao, Mohamed Boucadair, 2015-06-29, This document discusses the need and the mechanisms to dynamically update configuration of network monitoring devices to help identify distributed denial-of-service (DDoS) attacks in a network. Once an attack is signalled by a client or detected locally, provisioning cycles are triggered to program a set of network elements to undertake appropriate actions (including, blackhole, drop, rate- limit, or add to watch list) on the suspect traffic. "Root initiated routing state in RPL", Pascal Thubert, James Pylakutty, 2015-06-29, This document proposes a root-initiated protocol extension to RPL that enables to install a limited amount of downward routes in non- storing mode. This enables loose source routing down the DODAG. "Problem statement of SDN and NFV co-deployment in cloud datacenters", Rong Gu, Chen Li, Ruixue Wang, 2015-06-30, With the development of cloud computing technology, cloud datacenters have been influenced. Co-deployment of SDN and NFV technology shows its distinct advantages of vitalizing network resources in providing VPC services and SFC services.In order to deploy SDN and NFV in cloud datacenters, a resolution test has been conducted. According to the resolution test, SDN and NFV technology has been mature already for the commercial deployment in operators' network. However, there are some key problems on network architecture, virtualized platform, standard interfaces and so on to be working out in practical practice. "Special-Use Domain Name for Namecoin", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, Leif Ryge, 2015-06-30, This document registers a Special-Use Domain Name for use with the Namecoin system, as per RFC6761. "The .exit Special-Use Domain Name of Tor", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, Leif Ryge, 2015-06-30, This document registers a Special-Use Domain Name for use with the Tor Project, as per RFC6761. "Special-Use Domain Names of the GNU Name System", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, Leif Ryge, 2015-06-30, This document registers a set of Special-Use Domain Names for use with Peer-to-Peer (P2P) systems, as per RFC6761. "Special-Use Domain Names for I2P", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, Leif Ryge, 2015-06-30, This document registers a Special-Use Domain Name for use with the I2P Peer-to-Peer system, as per RFC6761. "The TCP Echo and TCP Echo Reply Options", Alexander Zimmermann, Richard Scheffenegger, Bob Briscoe, 2015-06-30, This document specifies the TCP Echo and TCP Echo Reply options. It provides a single field a TCP sender can use to store any type of data that a TCP receiver simply echo unmodified back. In contrast to the original TCP Echo and TCP Echo Reply options defined in RFC 1072 the options specified in this document have slightly different semantics and support a variable option length. "PMTUD Over Vxlan", Saumya Dikshit, 2015-07-01, IPv6 Path MTU Discovery between hosts/VM/servers/end-points connected over a Data-Center/Service-Provider Overlay Network, is still an unattended problem. It needs a converged solution to ensure optimal usage of network and computational resources for all devices hooked on to network in an enterprise or data-center deployment. "Namespace Resolution in Future Internet Architecture", Jianping Wang, Shucheng LIU, 2015-06-30, This document presents the architecture and implementation of an open and flexible namespace resolution mechanism to be used with Future Internet Architectures. This resolution mechanism allows the resolution of different network entities and can be adapted to the needs of network, application and service providers alike. "TCP Alternative Backoff with ECN (ABE)", Naeem Khademi, Michael Welzl, Grenville Armitage, Gorry Fairhurst, 2015-06-30, This memo updates the TCP sender-side reaction to a congestion notification received via Explicit Congestion Notification (ECN). The updated method is less conservative than the TCP reaction in response to loss. The intention is to achieve good throughput when the queue at the bottleneck is smaller than the bandwidth-delay- product of the connection. This is more likely when an Active Queue Management (AQM) mechanism has ECN-marked a packet than when a packet was lost. Future versions of this document will discuss SCTP as well as other transports using ECN. "CSS Requirements for RFCs", Heather Flanagan, 2015-06-30, While individuals may choose their own Cascading Style Sheet for presenting HTML-formatted RFCs, the default offered by the RFC Editor must meet certain requirements. This draft describes those requirements and is based on the classes defined in draft-hildebrand- 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. "Dynamic Forwarding by Constraint Options in SFC", chaungoctu@ssu.ac.kr, ddukki86@ssu.ac.kr, Souhwan Jung, 2015-06-30, This draft describes a Constraint-based Dynamic Control (CDC) inserted into SFC architecture to support dynamic assignment of Service Function (SF) with the use of filters functions. SFC Operators only need to provide general conditions for a chaining with CDC. "The OAuth 2.0 Risk notification and Token Revocation from Resource Server", ddukki86@ssu.ac.kr, Minho Park, Souhwan Jung, 2015-06-30, This document proposes the revocation of an access token in the case that a client uses the access token illegally or maliciously. Contrast to the existing revocation defined in RFC7009, the proposed revocation is initiated by a resource server when the abnormal behaviors of a client such as too many DB queries are detected. The revocation process after revocation initiation is based on RFC7009. "Root initiated routing state in RPL", Pascal Thubert, James Pylakutty, 2015-06-30, This document proposes a root-initiated protocol extension to RPL that enables to install a limited amount of downward routes in non- storing mode. This enables loose source routing down the DODAG. "BULK DNS Resource Records", john.woodworth@centurylink.com, Dean Ballew, Shashwath Raghavan, 2015-06-30, The BULK DNS resource record type defines a method of pattern based creation of DNS resource records to be used in place of NXDOMAIN errors which would normally be returned. These records are currently restricted to registered DNS resource record types A, AAAA, PTR and CNAME. The key benefit of the BULK resource record type is the simplification of maintaining "generic" record assignments which would otherwise be too many to manage or require scripts or proprietary methods as bind's $GENERATE. "Virtual multi-instancing for link state protocols", Shraddha Hegde, Mannan Venkatesan, Ross Callon, Alia Atlas, 2015-06-30, In networks with routers of different capabilities, some routers may not be able to participate fully in supporting new features or handling large databases and the associated flooding. In some cases, these restrictions can cause severe scalability issues for the network in general. This document proposes virtual multi-instances, a generic mechanism for OSPF and IS-IS, that allows groups of routers in specific topologies to have a reduced database and reduces the topology changes that are seen. The virtual multi-instances are specified so that no software or protocol changes are required in the restricted routers. Due to the potential number of virtual multi- instances in a network, the configuration is limited and is not specified per virtual instance. "IoT-Specific IPv6 Stateless Address Autoconfiguration with Modified EUI-64", Pyung-Soo Kim, 2015-06-30, An IoT-specific IPv6 stateless address autoconfiguration is suggested for diverse types of IoT devices. Both domain type and device type are defined and combined with 16-bit hexadecimal number, which is called the IoT type identifier. Then, this IoT type identifier is reflected in generating EUI-64 for each IoT device. An IoT-specific IPv6 address is developed using the stateless address autoconfiguration with the network prefix and the modified EUI-64. "Discovering the Capabilities of Flow-Aware Service Functions (a.k.a. Middleboxes): A PCP-based Approach", Mohamed Boucadair, Christian Jacquenet, 2015-06-30, This document specifies a solution to discover the capabilities of a flow-aware service function. The solution relies upon the use of the Port Control Protocol (PCP). This solution allows for applications to anticipate connectivity failures and to proceed with countermeasures (e.g., create a mapping for incoming connections, discover a mapping lifetime, discover an external IP address, avoid injecting some options in the outgoing packets, etc.). The propsoed approach allows, for example, to discover whether an upstream flow-aware service function is MPTCP- friendly (that is, it does not strip MPTCP signals) or SCTP- compliant, whether it embeds a firewall function, etc. or a combination thereof. "An Information Model for Basic Network Policy and Filter Rules", Susan Hares, Qin Wu, Jeff Tantsura, Russ White, 2015-07-01, This document contains the Basic Network Policy and Filters (BNP IM) Data Model which provides a policy model that support an ordered list of match-condition-action (aka event-condition-action (ECA)) for multiple layers (interface, L1-L4, application) and other factors (size of packet, time of day). The actions allow for setting actions (QOS and other), decapsulation, encapsulation, plus forwarding actions. The policy model can be used with the I2RS filter-based RIB. "YANG Data Model for RFC 7210 Key Table", Helen Chen, 2015-07-01, RFC 7210 defines a key table that consists of cryptographic keys that stores information for many different types of routing protocols to ensure message security. This document defines a YANG data model that represents the key table defined in RFC 7210, with the information necessary for YANG and NETCONF to provide routing protocol authentication. "Implications of Randomized Link Layers Addresses for IPv6 Address Assignment", Christian Huitema, 2015-07-01, Hosts may assign random link-layer addresses to network interfaces in an attempt to increase privacy and reduce trackability. Careless assignment of IPv6 addresses may negate the privacy advantages of random link-layer addresses. We propose simple solutions to ensure that IPv6 addresses do change whenever the link layer addresses change. "Operational Implications of IPv6 Packets with Extension Headers", Fernando Gont, Nick Hilliard, Gert Doering, Shucheng LIU, Warren Kumari, 2015-07-01, This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. "Architectural Framework for Self-Managed Networks with Fault Management Hierarchy", Mehmet Toy, 2015-07-01, This document describes a self-managed network identifying network problems during failures and repairing them. Self-managed Network Element (sNE) architectures and Network Management System (sNMS) architectures for centrally and distributedly managed networks are described. A hierarchy among repairing entities is defined. An in- band message format for Metro Ethernet networks is proposed for the fault management communication. "Deep Stats Inspection (DSI) and its Applications to Dynamic Service Function Chaining (D-SFC)", Bhumip Khasnabish, Wei Meng, Cui Wang, 2015-07-01, This draft focuses on using Deep Statistics Inspection (DSI) for smart analytics in Service function chaining. DSI can be utilized for service chaining in multi-tenant (Data centers) environment, automated load balancing (ALB), and automated disaster recovery (ADR). "Yang Data Model for Generic Routing Encapsulation (GRE)", Lianshu Zheng, Carlos Pignataro, Reinaldo Penno, Zishun Wang, 2015-07-02, This document defines a YANG data model that can be used to configure and manage Generic Routing Encapsulation (GRE). "Approach on encrypting DNS message over UDP", Peng Zuo, Hongtao Li, Ning Kong, XiaoDong Lee, Guangqing Deng, Jiankang Yao, Nan Wang, 2015-07-02, This document offers an approach to encrypt DNS queries and responses between the stub resolver and the recursive server over UDP to protect user privacy. The public key of the recursive server is distributed to the stub resolver through the Certificate Authority infrastructure, and the public key of the stub resolver is sent to the recursive server together with the DNS query where the public key is inserted to the additional section of the DNS query. Then the recursive server encrypts the DNS responses sent to the stub resolver with the public key of that stub resolver, and similarly the DNS query sent to the recursive server is encrypted by the stub resolver with the public key of that recursive server and thus the user privacy is protected. "DHCP Options for Network-Assisted Multipath TCP (MPTCP)", Mohamed Boucadair, Christian Jacquenet, Tirumaleswar Reddy, 2015-07-03, One of the promising deployment scenarios for Multipath TCP (MPTCP) is to enable a Customer Premises Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its network attachments. Because of the lack of MPTCP support at the server side, some service providers now consider a "network-assisted mode" that relies upon the activation of a dedicated function called: MPTCP Concentrator. This document focuses on the explicit deployment scheme where the identity of the MPTCP Concentrator(s) is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Multipath TCP (MPTCP) parameters. "Revision to Capability Codes Registration Procedures", John Scudder, 2015-07-02, This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Reserved for Private Use" is divided into three new ranges, respectively designated as "Standards Action", "Experimental" and "Reserved". "Content-Signature Header Field for HTTP", Martin Thomson, 2015-07-02, A Content-Signature header field is defined for use in HTTP. This header field carries a signature of the payload body of a message. "Information Model for Abstraction and Control of Transport Networks", Young Lee, Sergio Belotti, Daniele Ceccarelli, 2015-07-02, This draft provides an information model for abstraction and control of transport networks. "RFC 4960 Errata and Issues", Randall Stewart, Michael Tuexen, Karen E. E. Nielsen, 2015-07-03, This document is a compilation of issues found since the publication of RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time based way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. "Virtual Hub-and-Spoke in BGP EVPNs", Keyur Patel, Ali Sajassi, John Drake, Wim Henderickx, 2015-07-02, Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) applications and as the next generation virtual private LAN services in service provider (SP) applications. The use of host IP default route and host unknown MAC route within a DC is well understood in order to ensure that leaf nodes within a DC only learn and store host MAC and IP addresses for that DC. All other host MAC and IP addresses from remote DCs are learned and stored in DC GW nodes thus alleviating leaf nodes from learning host MAC and IP addresses from the remote DCs. This draft further optimizes the MAC and IP address learning at the leaf nodes such that a leaf node within a DC only needs to learn and store MAC and IP addresses associated with the sites directly connected to it. A leaf node does not need to learn and store MAC and IP addresses from any other leaf nodes thus reducing the number of learned MACs and IP addresses per EVI substantially. The modifications provided by this draft updates and extends RFC7024 for BGP EVPN Address Family. "TLS Client Puzzles Extension", Erik Nygren, 2015-07-02, Client puzzles allow a TLS server to defend itself against asymmetric DDoS attacks. In particular, it allows a server to request clients perform a selected amount of computation prior to the server performing expensive cryptographic operations. This allows servers to employ a layered defense that represents an improvement over pure rate-limiting strategies. Client puzzles are implemented as an extension to TLS 1.3 [I-D.ietf-tls-tls13] wherein a server can issue a HelloRetryRequest containing the puzzle as an extension. The client must then resend its ClientHello with the puzzle results in the extension. "ICN "Begin-End" Hop by Hop Fragmentation", marc.mosko@parc.com, Christian Tschudin, 2015-07-02, This document describes a simple hop-by-hop fragmentation scheme for ICN and mappings to the CCNx 1.0 and NDN packet formats, called "begin-end fragmentation". This scheme may be used at Layer 3 when ICN packets are used natively over a Layer 2 media which does not reorder packets. "Extensions to PCEP for Temporal LSP", Huaimo Chen, Mehmet Toy, Vic Liu, Lei Liu, 2015-07-02, This document specifies extensions to PCEP for initiating and maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a time interval or a sequence of time intervals, during which the LSP carries traffic. "Synchroniztion between resolvers and servers", Cui Wang, Wei Meng, Sunliang Huang, 2015-07-02, This document proposes how to synchronize the RRs in the resolvers along with the RRs in the authoritative servers when changes are occurred on the RRs in the authoritative servers. "Deterministic Networking Use Case in Mobile Network", Yiyong Zha, 2015-07-02, This document describes some high level use cases and scenarios with requirements on delay sensitive and deterministic networking. Not only the telecom industry but also vertical industries have been investigated. In addition to the 5G networking, industrial automation, automotive industry, media and gaming industry are typical related industries believed to be representative for the technical requirements on ultra-fast and ultra-reliability communications. "Simple Home Status Protocol", Markus Stenberg, 2015-07-02, This document describes yet another DNCP-based protocol, which uses HNCP-style transport, yet intentionally is incompatible with it so that TLVs of SHSP and HNCP can be handled using same transport channel and de/encoders, but individual implementations of the different protocols can ignore each other unless they support both protocols. "BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols", Pierre Pfister, IJsbrand Wijnands, Markus Stenberg, 2015-07-03, This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain. "TCP Fast Open Cookie for IPv6 prefixes", Mohammed HAWARI, 2015-07-03, In order to support applications that require a large number of addresses or address space, a host may be assigned an aggregate IPv6 prefix rather than one or more discrete IPv6 addresses. This document briefly describes cases where this may occur, and specifies an extension to TCP Fast Open [RFC7413] to allow a client to use a single TCP Fast Open cookie for an IPv6 prefix. "An IPv6 Extension Header for Service Function Chaining (SFC)", Christian Jacquenet, Mohamed Boucadair, 2015-07-03, This document specifies an IPv6 extension header for Service Function Chaining (SFC) purposes. This extension header is used by SFC data plane elements to make forwarding decisions in an IPv6-enabled SFC domain and it conveys metadata that are processed by SFC-aware nodes. This extension is intended to be used within a single administrative domain. "YANG Data Model for Tunnel Management", Aijun Wang, Zitao Wang, Zhuangyan, 2015-07-03, This document defines a YANG data model for the configuration and management of generic tunnels. The data model includes configuration data and state data. And it can serve as a base model which is augmented with technology-specific details in other, more specific tunnel models. "An MPTCP Profile for NAT- and Firewall-Free Networks: Network-Assisted MPTCP Deployments", Mohamed Boucadair, Christian Jacquenet, Pierrick Seite, Olivier Bonaventure, Deng Lingli, 2015-07-03, One of the promising deployment scenarios for Multipath TCP (MPTCP) is to enable a Customer Premises Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of such resources, thereby providing better serviceability overall (including whenever the CPE fails to connect to one of the access networks). This document specifies a MPTCP profile for such deployments in network regions that are firewall- and NAT-free. "Guidelines for Translation of UML Information Model to YANG Data Model", Scott Mansfield, Bernd Zeuner, Nigel Davis, Yuji Tochio, Eve Varma, 2015-07-03, This document defines guidelines for translation of data modeled with UML to YANG including mapping of object classes, attributes, data types, associations, interfaces, operations and operation parameters, notifications, and lifecycle. "Common Interface Extension YANG Data Models", Robert Wilton, David Ball, Tapraj Singh, Selvakumar Sivaraj, 2015-07-03, This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. "A YANG data model for Protocol-Independent Multicast (PIM)", Xufeng Liu, Pete McAllister, Anish Peter, 2015-07-03, This document defines a YANG data model that can be used to configure Protocol Independent Multicast (PIM) devices. "SPUD Use Cases", Mirja Kuehlewind, Brian Trammell, 2015-07-03, The Substrate Protocol for User Datagrams (SPUD) BoF session at the IETF 92 meeting in Dallas in March 2015 identified the potential need for a UDP-based encapsulation protocol to allow explicit cooperation with middleboxes while using new, encrypted transport protocols. This document summarizes the use cases discuss at the BoF and thereby proposes a structure for the description of further use cases. "VNF Orchestration For Automated Resiliency in Service Chains", Giacomo Bernini, Vincenzo Maffione, Diego Lopez, Pedro Aranda, 2015-07-03, Network Function Virtualization (NFV) aims at evolving the way network operators design, deploy and provision their networks by leveraging standard IT virtualization technologies to move and consolidate a wide range of network functions and services onto industry standard high volume servers, switches and storage. Primary area of impact for operators is the network edge, being stimulated by the recent updates on NFV and SDN. In fact, operators are looking at their future datacenters and Points of Presence (PoPs) as increasingly dynamic infrastructures to deploy Virtualized Network Functions (VNFs) and on-demand chained services with high elasticity. This document presents an orchestration framework for automated deployment of highly available VNF chains. Resiliency of VNFs and chained services is a key requirement for operators to improve, ease, automate and speed up services lifecycle management. The proposed VNFs orchestration framework is also positioned with respect to current NFV and Service Function Chaining (SFC) architectures and solutions. "Extensions to MPLS for Temporal LSP", Huaimo Chen, Mehmet Toy, Vic Liu, Lei Liu, 2015-07-03, This document specifies extensions to RSVP-TE for creating and maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a time interval or a sequence of time intervals. "Extensions to OSPF for Temporal LSP", Huaimo Chen, Mehmet Toy, Vic Liu, Lei Liu, 2015-07-03, This document specifies extensions to OSPF for distributing Traffic Engineering (TE) information on a link in a sequence of time intervals. "IS-IS over IPv6", C. Franke, 2015-07-03, In this draft, a method to transmit IS-IS PDUs as IPv6 packets is described. While the default encapsulation of IS-IS is specified directly on top of the link-layer, making it necessary for IS-IS to be specified for each link-layer it should be used on, the proposed method allows for IS-IS to run on any link-layers supporting IPv6. "Benchmarking Virtual Switches in OPNFV", Maryam Tahhan, Billy O'Mahony, Al Morton, 2015-07-03, 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. "Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments", Vishnu Pavan Beeram, Ina Minei, Rob Shakir, Ebben Aries, Dante Pacella, Tarek Saad, Markus Jork, 2015-07-03, The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually and the onus is on RSVP-TE implementations across the board to keep up with this increasing demand. This document makes a set of implementation recommendations to help RSVP-TE deployments push the envelope on scaling and advocates the use of a couple of techniques - "Refresh Interval Independent RSVP (RI-RSVP)" and "Per-Peer flow-control" - for improving scaling. "E-mail Authentication for Internationalized Mail", John Levine, 2015-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 a domain names when using SPF, DKIM, and DMARC. "IP/ICMP Translation Algorithm (rfc6145bis)", Xing Li, Congxiao Bao, Fred Baker, Tore Anderson, Fernando Gont, 2015-07-04, This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document updates RFC 6145. "Constrained Signaling Over LR-WAN", Alexander Pelov, Laurent Toutain, Yannick Delibie, 2015-07-04, This document presents a new type of far-reaching, low-rate radio technologies and an extensible mechanism to operate these networks based on CoAP. The emerging Wide Area Networks based on them - Low- Rate WAN (LR-WAN) preset a particular set of constraints, which places them at the intersection of infrastructure networks, ultra- dense networks, delay-tolerant networks and low-power and lossy networks. The main objectives of LR-WAN signaling is to minimize the number of exchanged messages, minimize the size of each message in a secure and extensible manner. This document describes the use of the Constrained Application Protocol (CoAP) as the main signaling protocol for LR-WANs, over which minimal messages are exchanged allowing the full operation of the network, such as authentication, authorization, and management. The use of CoAP signaling provides a generic mechanism that can be applied to different LR-WAN technologies. "VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, Samir Thoria, Tapraj Singh, John Drake, Jeff Tantsura, 2015-07-04, 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. "Evaluation Test Cases for Interactive Real-Time Media over Wi-Fi Networks", Jian Fu, Xiaoqing Zhu, Michael Ramalho, Wei-Tian Tan, 2015-07-06, An increasing proportion of multimedia communication applications, including real-time interactive voice and video, are transported over Wi-Fi networks (i.e., wireless local area networks following IEEE 802.11 standards) today. It is therefore important to evaluate candidate congestion control schemes designed in the RMCAT Working Group over test cases that include Wi-Fi access links. This draft serves such a purpose, and is complementary to [I-D.ietf-rmcat-eval-test] and [I-D.draft-sarker-rmcat-cellular-eval-test-cases] "Issues to SFC OAM Framework", Lei Zhu, 2015-07-05, This document is motivated to illustrate SFC OAM issues from framework perspective. This document contains the problems, requirements and framework issues to support operation and management in SFC architecture. These SFC OAM framework considerations are applicable for vitalization platform. "CERNET deployment of IVI/MAP-T in an IPv6-only network", Xing Li, Congxiao Bao, Guoliang Han, Maojia Sheng, 2015-07-05, This document presents the China Education and Research Network (CERNET)'s IPv4 as a Service (IPv4aaS) design, deployment and operation experience. The techniques used are IPv4/IPv6 stateless translation both in the forms of single translation (IVI, for IPv6-only servers) and double translation (MAP-T, for dual-stack clients). "Refresh Interval Independent FRR Facility Protection", Chandra R, Ina Minei, Ebben Aries, Dante Pacella, Tarek Saad, 2015-07-05, This document defines RSVP-TE extensions to facilitate refresh- interval independent FRR facility protection. "Human Rights Protocol Considerations Glossary", Daniel Kahn Gillmor, Niels Oever, Avri Doria, 2015-07-05, This document presents a glossary of terms used to map between concepts common in human rights discussions and engineering discussions. It is intended to facilitate work by the proposed Human Rights Protocol Considerations research group, as well as other authors within the IETF. "Socket API Extension for MIF PvD Architecture", Dapeng Liu, 2015-07-05, IETF MIF working group defines the multiple provisioning domain architecture. This document proposes API extension for the PvD-aware node to support the MIF PvD architecture. "Yang Data Model for Unified Tunnel", Zhenbin Li, Xia Chen, 2015-07-05, This document defines a YANG data model for the unified tunnel. The data model includes the operational state of tunnels. "Multipath TCP Address Advertisement", Olivier Bonaventure, 2015-07-05, Multipath TCP [RFC6824] defines the ADD_ADDR option to allow a host to announce its addresses to the remote host. In this document we analyze some of the issues with the address advertisement technique defined [RFC6824] and propose some modifications to mitigate these problems. We also show that the reverse DNS could be an excellent alternative to advertise the stable addresses of a server. "Extensible Property Maps for the ALTO Protocol", Wendy Roome, 2015-07-05, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to other entity domains, and by presenting those properties as maps, similar to the network and cost maps in ALTO. "A Data Model for Locally Generated Routes in Service Provider Networks", Anees Shaikh, Joshua George, Rob Shakir, Feihong Chen, 2015-07-05, This document defines a YANG data model for configuring and managing locally generated routes in a vendor-neutral way and based on operational best practice. Locally generated routes are those created by configuration, rather than by dynamic routing protocols. Such routes include static routes, locally created aggregate routes for reducing the number of constituent routes that must be advertised, summary routes for IGPs, etc. "Advanced Resource Directory Features", Akbar Rahman, Chonggang Wang, 2015-07-05, The Resource Directory (RD) is a key element for successful deployments of constrained networks. Similar to the HTTP web search engines (e.g. Google, Bing), the RD for CoAP should also support useful search query responses beyond a basic listing of relevant links. This document proposes several new features to be considered for the RD. The only goal of this document is to trigger discussion in the CORE WG so that all relevant features for RD evolution are taken into account during CORE re-charter activities. "Real-time Transport Control Protocol (RTCP) Feedback Message Extension for Image Control Message", Rachel Huang, Roni Even, 2015-07-05, This document introduces a method to let receivers control the part of the full video image that they wish to watch. It specifies an extension to the messages defined in the Audio-Visual Profile with Feedback (AVPF), and it can be applied to any RTP video applications. "IPv6 Service function Chain", Cui Wang, Wei Meng, 2015-07-05, Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. This document tries to describe how to use IPv6 data plane and IPv6 extension headers to realize service function chain in IPv6 network. "Use-case and Requirements for Multi-domain Operation Plane Change", Toshiaki Suzuki, 2015-07-05, This document provides a use-case and requirements that address the need for facilitating dynamic change of an operation plane, which includes virtually prepared multiple networks and/or data transmission paths, from a current operation one to a backup one during scheduled maintenance or an emergency such as a network disaster. Specifically, the necessity of interfaces to establish consistent end-to-end data transmission paths over multiple domain networks is addressed. "Usecase and hierarchical models of service function chaining in cloud datacenters", Rong Gu, Chen Li, 2015-07-05, In providing the service functions such as VPN, FW, LB, DPI and so on, usecase and hierarchical models in cloud datacenters are introduced.In order to realize the practical deployment,the cascade and hang-on network architecture are comparied to make the guidance.By adopting the hang-on network architecture and the hierarchical models, services to the tenants are more flexible and elastic while services to the operators are more convenient in management. "The topology of service function chaining", Qiao Fu, Joel Halpern, Hui Deng, 2015-07-05, This document proposes a deployment topology of Service Function Chaining(SFC). The topology is in accordance with the SFC architecture in [I-D.ietf-sfc-architecture]. Currently, such architecture only includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, without any instruction for the field deployment. It is still difficult to map from the architecture to a real deployment of SFC. In this document, we propose this topology which will give instructions for the field deployments. We further propose a VCPE usecase of SFC in the transport network, which explains the details of the deployment topology. "Motivations, usecases and Models of VCPE", Qiao Fu, Sri Gundavelli, Hui Deng, 2015-07-05, This document introduces the concept of Virtual Customer Premises Equipment (VCPE). Such concept was first proposed in Broadband Forum (BBF) as Network Enhanced Residential Gateway (NERG). The VCPE is the Home Agent (HA) of the Mobile Nodes (MN) attached to the physical CPE (pCPE). In this document, we explain the motivation and advantages of VCPE. Three usecases of VCPE is further discussed in the enterprise network, the residential network, and the Internet of Things (IoT) Network. Two models of field deployment of VCPE are discussed afterwards. The models of VCPE decompose the Control Plane (CP) and the Data Plane (DP), which makes it easier for the deployment of the distributed mobility model. "IPv6 Transition Technologies Selection in NFV", Hui Deng, Min Hui, 2015-07-05, Nowadays, many IPv6 transition technologies have been proposed, such as Dual-Stack, 6rd and so on. A CPE may support some of them instead of only one. But the ISPs always support different kinds of transition technologies, such as Dual-Stack, DS-lite and so on. So they must control all the CPEs to match the exact transition tech through some standard messages. When the ISP network uses NFV, the message communication will between the network gateway and the V-CPE to configure the IPv6 transition technology in CPE. "Carrying Label Information for BGP FlowSpec", LQD, Jianjie You, 2015-07-05, 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. Meanwhile, using label for FlowSpec rule can improve forwarding performance in BGP VPN/MPLS networks. "VLAN Configuration Considerations in Split-NVE", Li Yizhou, Lucy Yong, 2015-07-05, In a Split-NVE structure, a control plane protocol between a hypervisor and its associated external NVE(s) to distribute the virtual machine networking state and the relevant attributes. One of the key attributes to be negotiated is VLAN ID which is the most common locally-significant tag for carrying traffic associated with a specific virtual network. This document provides the informational guides on how to configure the VLAN IDs to local networks in Split- NVE structure. "RTP Payload Format for Interleaved Packets", Rachel Huang, 2015-07-05, This memo introduces a common RTP encapsulation for interleaved media. This method can be applied to any RTP payload formats for any applications when latency is not an issue. "Requirements of Abstract Alarm Report in ACTN architecture", Yunbin Xu, Guoying Zhang, 2015-07-05, This draft provides a set of requirements for alarm abstraction and report of transport networks in the ACTN architecture. "Human Rights Protocol Considerations Methodology", Joana Varon, Corinne Cath, 2015-07-05, This document presents steps undertaken for developing a methodology to map engineering concepts at the protocol level that may be related to promotion and protection of Human Rights, particularly the right to freedom of expression and association. It feeds upon and is intended to facilitate the work done by the proposed Human Rights Protocol Considerations research group, as well as other authors within the IETF. Exemplary work [RFC1984] [RFC6973] [RFC7258] has already been done in the IETF on privacy issues that should be considered when creating an Internet protocol. But, beyond privacy considerations, concerns for freedom of expression and association were also a strong part of the world-view of the community involved in developing the first Internet protocols. Indeed, promoting open, secure and reliable connectivity is essential for these rights. But how are this concepts addressed in the protocol level? Are there others? This ID is intended to explain research work done so far and to explore possible methodological approaches to move further on exploring and exposing the relations between standards and protocols and the promotion and protection of the rights to freedom of expression and association. Discussion on this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/admindb/hrpc "Dissemination of Flow Specification Rules for NVO3", Hao Weiguo, Shunwan Zhuang, Zhenbin Li, 2015-07-05, This document defines BGP flow-spec extension for NVO3. A Flag in BGP Path Attribute is introduced to indicate the Flow-spec rules imposing on NVO3 outer or inner layer. A new subset of NVO3 specific component types and extended community also are defined. "Multicast Anchoring in DMM", gomjae@dcn.ssu.ac.kr, Young-Han Kim, 2015-07-05, In this draft, we define multicast support functions in a Distributed Mobility Management (DMM) environment. Based on the decomposed mobility management functions in [RFC7429], each defined multicast support function can be located and operated with DMM functions. "Avoiding Repeated Preemption of Low-Priority TE LSPs - Recommendations", Sudharsana Venkataraman, 2015-07-05, When a high priority LSP is being setup, if there is reservation contention on a link along the path to the destination, any low priority LSP taking the link could get preempted and eventually rerouted. Low priority LSPs could suffer preemption repeatedly when they are placed in succession on heavily used links that have very less remaining bandwidth. This document describes a solution to avoid repeated preemption of low priority LSPs in the network. "Mail Divide Framework", Takehito Akagiri, Kaoru Maeda, Kouji Okada, lef, Masaki Kase, 2015-07-05, Mail Divide Framework (MDF) is a recipient driven partitioning framework for E-Mail delivery. A protocol to divide mail delivery at the source of the message is defined in this draft. A mechanism called Reputation Service Provider is also introduced so that a third-party authority can assure senders' trust. With MDF, subdomaining is used for category-specific MTA designation. Senders decide which category the outgoing mail belongs. It then looks up DNS TXT record to find whether the recipient advertises a specific server for that category. The specified server puts the received mail into a corresponding per-category inbox for the user. "TRILL: Traceable OAM", Li Yizhou, Donald Eastlake, Hao Chen, Deepak Kumar, Sujay Gupta, 2015-07-06, TRILL fault management [RFC7455] specifies the messages and operations for OAM in TRILL network. The sender collects the replies for the OAM-relevant request it sent and uses the replies as the indication of the network faults. In certain circumstances the sender needs to collect multiple replies to isolate the fault, e.g. repetitively sending Path Trace Messages (PTM) with increasing value of hop count and collecting the replies on them to figure out the fault point of certain path. With the increasing deployment of Software Defined Network (SDN), a centralized management server can be used to help with fault management. The server then is responsible to collect OAM messages and analyze them to either isolate the network fault or compile overall OAM information. It naturally uses SDN structure to alleviate the effort of the requester node and provide a centralized solution to produce the operation and management feedback of the network. This document specifies the extensions of TRILL OAM message and the operations about the network nodes and the centralized management server to trace and collect OAM relevant messages for further analysis. "Upstream Assigned Label Collision Solution", Zheng Zhang, Ying Cheng, 2015-07-06, The upstream-assigned label is used to identify the specific multicast flow. In MVPN technology RFC6513, it says: "This procedure requires each egress PE to support a separate label space for every other PE. The egress PEs creates a forwarding entry for the upstream-assigned MPLS label, allocated by the ingress PE, in this label space." In common scenario, the "separate label space" is planned by network administrator in advance. For the stable network, the method of allocating the separate label space is easy and practicable. But when the network changes dynamically, it is very hard to allocate the separate label space in advance. The planned label space is probably insufficient. That leads to collision when PE uses the common label space to allocate upstream-assigned label. Therefore we need a flexible solution for the collision of upstream-assigned label in the dynamically changing network. "ACTN : Use case for Multi Tenant VNO", Kenji Kumaki, Takuya Miyasaka, 2015-07-06, This document provides a use case that addresses the need for facilitating virtual network operation: creation and operation of multi-tenant virtual networks that use the common core network resources. This will accelerate a rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. This use case addresses the aforementioned needs within a single operator network. "Codec-Independent Selective Forwarding", Bernard Aboba, 2015-07-06, Selective Forwarding Units (SFUs) supporting Scalable Video Coding (SVC) typically parse the RTP payload in the forwarding plane, and often utilize codec-specific control messages within the control plane. As a result, the control and/or forwarding planes of these implementations need to be modified (sometimes substantially) in order to support additional video codecs. With SFUs now supporting VP8 in addition to H.264/SVC, and with additional video codecs expected to become popular, the inflexibility of SFU designs that depend on RTP payload parsing has become increasingly apparent. In addition, these designs cannot function where the RTP payload is inaccessible, such as when it is encrypted with a key not available to the SFU. Based on a summary of SFU implementation practice, this document develops requirements for codec-independent SFUs. "YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, 2015-07-06, This document defines a YANG data model for BIER configuration and operation. "Host address availability recommendations", Lorenzo Colitti, Vint Cerf, Stuart Cheshire, 2015-07-06, This document recommends that networks provide general-purpose end hosts with multiple global addresses, and describes options for doing so. "Optimal Ate Pairing", Akihiro Kato, Michael Scott, Tetsutaro Kobayashi, Yuto Kawahara, 2015-07-06, Pairing is a special map from two elliptic curve that called Pairing- friend curves to a finite field and is useful mathematical tools for constructing cryptographic primitives. It allows us to construct powerful primitives. (e.g. [3] and [4]) There are some types of pairing and its choice has an impact on the performance of the primitive. For example, Tate Pairing [3] and Ate Pairing [4] are specified in IETF. This memo focuses on Optimal Ate Pairing [2] which is an improvement of Ate Pairing. This memo defines Optimal Ate Pairing for any pairing-friendly curve. We can obtain concrete algorithm by deciding parameters and building blocks based on the form of a curve and the description in this memo. It enables us to reduce the cost for specifying Optimal Ate Pairing over additional curves. Furthermore, this memo provides concrete algorithm for Optimal Ate Pairing over BN-curves [7] and its test vectors. "YANG Models Required for Managing Customer Premises Equipment (CPE) Devices", Ian Farrer, Qi Sun, Sladjana Zoric, Mikael Abrahamsson, 2015-07-06, This document collects together the YANG models necessary for managing a NETCONF-enabled Customer Premises Equipment (CPE) device. "FSU Key Exchange", Akihiro Kato, Thomas Hardjono, Tetsutaro Kobayashi, Tsunekazu Saito, Koutarou Suzuki, 2015-07-06, This draft proposes an identity-based authenticated key exchange protocol following the extended Canetti-Krawczyk (id-eCK) model. The protocol is currently the most efficient among the id-eCK protocols. "MAP-T Trial in ChinaTelecom", Chongfeng Xie, Chen Li, Congxiao Bao, Guoliang Han, Xing Li, 2015-07-06, With the depletion of the IPv4 address space, large-scale SPs are now faced with the real option to deploy IPv6 in a timely manner. In order to achieve smooth transition to IPv6, migration tools should be introduced for different deployment models. Among different IPv6 transition mechanisms, MAP-T is a stateless translation method which can directly translate IPv4 packet to IPv6 packet. This document describes the challenges and requirements for large SP to deploy IPv6 in operational network, the experimental results of MAP-T in our laboratory and the field trials in large SP operational network. "Secure Real-time Transport Protocol (SRTP) for Cloud Services", John Mattsson, Mats Naslund, 2015-07-06, In order to support use cases when two or more end-points communicate via one (or more) cloud service (e.g. virtualized cloud-based conferencing) that are not trusted to access the media content, this document describes the use of so called end-to-end (inner) and hop- by-hop (outer) cryptographic transforms within the Secure Real-time Transport Protocol (SRTP). One of the main aspects of the transforms is to make the confidentiality and message authentication independent of the RTP header. Another central aspect is to enable identification of the cryptographic contexts (keys etc.). Besides the security of the end-points, also trust assumptions regarding the cloud services are addressed. "GRE Tunnel Bonding", Nicolai Leymann, Cornelius Heidemann, Mingui Zhang, Margaret Wasserman, 2015-07-06, It is an emerging demand to provide redundancy and load-sharing across wired and cellular links from a single service provider so that one customer is provided with "Hybrid Access" to the bonding of multiple heterogeneous connections. In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for Hybrid Access. In GRE Tunnel Bonding, GRE tunnels per network connections are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each composing connection, the bonding connection promises increased access capacity and improved reliability. "Paths Extension for the ALTO Protocol", Piotr Wydrych, Qiao Fu, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) protocol has been standardized in RFC7285 to ease better-than-random overlay connection management. However, through the base protocol it is not possible to differenciate paths from a given source to a given destination and provide an ALTO client with a detailed information of sending traffic through these paths. This document describes an extension to the ALTO protocol allowing for representation of paths in the network maps, cost maps, and endpoint cost calculation. Morever, this document defines a new path computation service. "Intent-Based Nemo Problem statement", Susan Hares, 2015-07-06, As IP networks grow more complicated, these networks require a new interaction mechanism between customers and their networks based on intent rather than detailed specifics. An intent-based protocol language is need to enable customers to easily describe their diverse intent for network connectivity to the network management systems. This document describes the problem Intent-Based NEtwork Modeling (IB-Nemo) language is trying to solve, a summary of the use cases that demonstrate this problem, and a proposed scope of work. Part of the scope is the validation of the language as a minimal subset. The IB-NEMO language is a protocol language for interactions between an application and a network manager/controller. Some would call this boundary between the application and the network management system as northbound interface (NBI), and any protocol language that crosses this as an NBI. IB-Nemo focuses on creating minimal subset of the total possible Intent-Based desired commands. By creating a minimal subset (about 20% of the total possible), the IB-Nemo language can be a simple Intent interface for most applications (hopefully 80%). Part of validation of this language is to to determine what data models should result in the network controller from different use cases. This way as IB-Nemo protocol language is reduced the effort can verify that the critical information is stilled passed. "PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful", Colby Barth, Raveendra Torvi, Phil Bedard, 2015-07-06, Stateful PCE [ietf-pce-stateful-pce] can apply global concurrent optimizations to optimize LSP placement. In a deployment where a PCE is used to compute all the paths, it may be beneficial for the local protection paths to also be computed by the PCE. This document defines extensions needed for the setup and management of RSVP-TE protection paths by the PCE. "Authentication architecture for a group of constrained devices", yangun@dcn.ssu.ac.kr, ykpark@dcn.ssu.ac.kr, Young-Han Kim, Namhi Kang, 2015-07-06, Constrained devices have a limitation in adapting various general cryptography mechanisms since they have limited processing power, storage space and transmission capacities. Moreover, in an environment that has a large number of constrained devices, the device authentication and authorization procedure causes serious burdens. Therefore, this draft proposes a group authentication mechanism to solve existing problems. "DHCPv6 Prefix Length Hint Issues", Yong Cui, Tianxiang Li, Cong Liu, 2015-07-06, DHCPv6 Prefix Delegation [RFC3633] allows a client to set a hint value in the prefix-length field of 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 the different situation involving the the prefix length hint. "BGP FlowSpec Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang Ou, Yujia Luo, Shunwan Zhuang, Nan Wu, 2015-07-06, This document describes a mechanism to use BGP Flowspec address family [RFC5575] as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP FS RPD). "Initial Performance Metric Registry Entries", Al Morton, Marcelo Bagnulo, Philip Eardley, Kevin D'Souza, 2015-07-06, This memo defines the Initial Entries for the Performance Metrics Registry. "Improving Multipath TCP Backup Subflows", Olivier Bonaventure, Quentin De Coninck, Matthieu Baerts, Fabien Duchene, benjamin.hesmans@uclouvain.be, 2015-07-06, This document documents some issues with the current definition of the backup subflows in [RFC6824]. The solution proposed in [RFC6824] works well when a subflow completely fails. However, if a subflow suffers from huge packet losses, but still remains up, then the delay to switch to the backup subflow may be very long. We propose to measure the evolution of the retransmission timer (RTO) to detect the bad performance of subflows. "Yang Data Model for IEEE 1588v2", Yuanlong Jiang, Xian Liu, Jinchun Xu, 2015-07-06, This document defines a YANG data model for the configuration of IEEE 1588v2 devices and clocks, and also retrieval of the configuration information, data set and running states of IEEE 1588v2 clocks. "Multicast mobility deployment scenarios over distributed mobility management", Kyoungjae Sun, Van-Giang Nguyen, xuan@dcn.ssu.ac.kr, Younghan Kim, 2015-07-06, This document presents deployment scenarios for supporting IP multicast over distributed mobility management (DMM) architecture, which considers the separation of the control and the data planes. This document describes three main use cases of IP multicast deployments over DMM depending on the placement of control and data plane functional entities. "Operational Experience of MAP-E", Akira Nakagawa, 2015-07-06, This document describes operational experience of "Mapping of Address and Port with Encapsulation (MAP-E)". "Probing MPTCP Subflows", Mohamed Boucadair, Christian Jacquenet, 2015-07-06, This document specifies an extension to Multipath TCP (MPTCP) that is meant to assess whether a path used to establish a given subflow is MPTCP-friendly, i.e., intermediate nodes involved in that path do not alter nor strip MPTCP options, which would prevent the establishment of MPTCP communications along that path. A new flag bit, called Probe Flag (P-flag) is defined for this purpose. This document updates RFC6824. "RADIUS attributes commonly used in fixed networks", Devasena Morrissette, Frederic Klamm, Lionel Morand, 2015-07-06, There is a set of Remote Authentication Dial-In User Service attributes which have been widely used in different types of fixed networks though they don't appear as standard attributes. Each of these attributes has for long been part of many vendor dictionnaries, thus presented in different approaches and different syntaxes. This document try to solve this in an effort to present them in a standard, common way, based on approaches found in multiple dictionnaries. "YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice Brissette, Reshad Rahman, Kamran Raza, Zhenbin Li, Shunwan Zhuang, Haibo Wang, Helen Chen, Mathew Bocci, Jonathan Hardwick, Santosh Esale, Kishore Tiruveedhula, Tapraj Singh, Iftekhar Hussain, Bin Wen, Jason Walker, Nick Delregno, Luay Jalil, Maria Joecylyn, 2015-07-06, This document describes a YANG data model for Layer 2 VPN services over MPLS networks. These services include Virtual Private Wire Service (VPWS), Virtual Private LAN service (VPLS) and Ethernet Virtual Private Service (EVPN) that uses LDP and BGP signaled Pseudowires. This document mainly focuses on L2VPN VPWS, other services are for future investigations. "ALTO Extensions for Multi-Source Information Collection", Kai Gao, Yang Yang, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) protocol enables the distribution of certain network information to applications. Hence, a fundamental functionality of an ALTO server is to collect general network information, especially from multiple "information sources". In this document, we propose a preliminary solution to standardize the process of information collection for ALTO servers by extending the ALTO protocol with some new services, which can also serve as a unified approach of network information distribution. "Problems with the Public Key Infrastructure (PKI) for the World Wide Web", Russ Housley, Karen O'Donoghue, 2015-07-06, This document describes the technical and non-technical problems with the current Public Key Infrastructure (PKI) used for the World Wide Web. Some potential technical improvements are considered, and some non-technical approaches to improvements are discussed. "Autonomic Functions Coordination", Laurent Ciavaglia, Pierre Peloso, 2015-07-06, This document describes a management solution capable of avoiding conflicts between autonomic functions. The objective of such a solution is to avoid network instabilities, by insuring that the autonomic functions pursuing different goals will cooperate instead of antagonize each other. This document provides both requirements and specifications for such a solution. "A Session Initiation Protocol (SIP) Feature Tag for Back-to-Back User Agents (B2BUAs)", Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro, 2015-07-06, The User Agent capabilities specification allows Session Initiation Protocol (SIP) User Agents to convey their capabilities and characteristics to other User Agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. Amongst those capabilities are the type of User Agent that is available at a SIP Uniform Resource Identifier (URI). This document extends the User Agent capabilities specification to allow indication of Back-to-Back User Agent (B2BUA) types. "Service Centric Networking Architecture for Smart Homes", Bo Lv, Yue Jia, Min Liang, 2015-07-06, We propose a general service centric homenet architecture, which can handle the diversity of devices, services, applications and context. Especially, we focus on building an overall home network topology, routing and naming structures, to fit SCN into a home network. In the future, we will discuss homenet caching, mobility and security in details. "Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways", Vincent Roca, Saikou Fall, 2015-07-06, This document introduces the "Packet Too Big"-"Packet Too Small" Internet Control Message Protocol (ICMP) based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the unsecure network where he only sees encrypted packets, can force a gateway to reduce the Path Maximum Transmission Unit (PMTU) of an IPsec tunnel to the minimum, which can trigger severe issues for the hosts behind this gateway: with a Linux host, depending on the PMTU discovery algorithm in use (i.e., PMTUd versus PLPMTUd) and protocol (TCP versus UDP), the attack either creates a Denial of Service or major performance penalties. This attack highlights two fundamental problems, namely: (1) the impossibility to distinguish legitimate from illegitimate ICMP packets coming from the untrusted network, and (2) the contradictions in the way Path MTU is managed by some end hosts when this Path MTU is below the minimum packet size any link should support because of the IPsec encapsulation. "Key Discovery Service", Matthew Miller, Suhas Nandakumar, 2015-07-06, A typical requirement with any cryptographic key management system is to provide discovery, retrieval, distribution, and management of keys across entities needing to perform the necessary security operations. However there exists no standard mechanism to automatically discovery the keys, but rather the keys are either provisioned statically or shared beforehand via non standard mechanisms. This document defines machanisms for an entity to automatically discover the key(s) associated with other entities using the WebFinger protocol. "Updates on EVPN BUM Procedures", Jeffrey Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, 2015-07-06, This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. "Issue with current STIR scenario", Chen Zhang, Hui Deng, 2015-07-06, This document introduces couple of scenarios have been identified to find out that certificate based solution has some limitation. "Low Energy Requirements for WebPush", Herve Ruellan, Kensuke Yasuma, Tomoya Sakai, 2015-07-06, Many devices are now connected to the Internet. Receiving instantaneous notifications from the Web is an appealing but possibly power-hungry feature. This can be a substantial problem for light devices with limited battery capacities. WebPush alleviates this problem by enabling a server to push notifications to the device instead of having the device regularly poll the server. This is a first step towards more energy efficient devices, but is still not sufficient for enabling batteries to last weeks or months without recharging. "Dynamic IPv4 Provisioning for Lightweight 4over6", Cong Liu, Qi Sun, Jianping Wu, Ian Farrer, 2015-07-06, Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an IPv4 over IPv6 hub and spoke mechanism that provides overlay IPv4 services in an IPv6-only access network. Provisioning IPv4 addresses and port sets to customers is the core function of the Lightweight 4over6 control plane. [I-D.ietf-softwire-lw4over6] describes the use of DHCPv6 for deterministic IPv4 provisioning. This document describes a dynamic IPv4 provisioning mode for Lightweight 4over6 that based on DHCPv4 over DHCPv6 [RFC7341]. "YANG Data Model for SAVI", Wei Meng, Cui Wang, 2015-07-06, This document defines a YANG data model for SAVI. "Middlebox Communication Enabling for Enhanced User Experience", Attila Mihaly, Szilveszter Nadas, 2015-07-06, In this draft we address some of the key discussion points related to the scope of Substrate Protocol for User Datagrams (SPUD). Specifically, we show how we can define the middlebox communication framework such that it allows uneven resource sharing on the path among the endpoints enhancing in this way the user experience. Issues related to trust and incentives as well as how to support user decisions in this eco-system are clarified. "Bandwidth aggregation for multiple interface node", 4c 69 61 6e 67, Hui Deng, 2015-07-06, This document describes the support of bandwidth aggregation for a mif node. By introducing bandwidth aggregation, a mif node can use the multihomed interfaces to achieve bandwidth enhancement, traffic steering and improved reliability. "Firewall Traversal for WebRTC", Cullen Jennings, Suhas Nandakumar, Jonathan Rosenberg, 2015-07-06, Traversal of RTP through corporate firewalls has traditionally been complex, requiring the deployment of Session Border Controllers (SBCs) or wide open pinholes. This draft proposes a simple technique that allows WebRTC based RTP traffic to traverse firewalls without complex firewall configuration and without deployment of SBCs or other middleboxes. "Static Routing for DTN", John Dowdell, Nabil Benamar, 2015-07-06, Static Routing in Delay-Tolerant Networks cannot make full use of standard IPv4 or IPv6 static routing as defined in section 7.4 of [RFC1812], due to the DTN feature of Late Binding where the IP address or addresses associated with an Endpoint Identifier may not be known when a packet is originated. This draft presents a specification for static routing in the DTN environment. "Network Device YANG Organizational Model", Acee Lindem, Lou Berger, Dean Bogdanovic, Christian Hopps, 2015-07-06, This document presents an approach for organizing YANG models in a comprehensive structure that defines how individual models may be composed to configure and operate network infrastructure and services. The structure is itself represented as a YANG model rooted at a device, with all of the related component models logically organized in a way that is operationally intuitive. This document is derived from work submitted to the IETF by members of the informal OpenConfig working group of network operators and is a product of the Routing Area YANG Architecture design team. "Congestion Control and Codec interactions in RTP Applications", Mo Zanaty, Varun Singh, Suhas Nandakumar, Zaheduzzaman Sarker, 2015-07-06, Interactive real-time media applications that use the Real-time Transport Protocol (RTP) over the User Datagram Protocol (UDP) must use congestion control techniques above the UDP layer since it provides none. This memo describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, specifically the media codec control layer, and the components dedicated to congestion control functions. "TRILL Transparent Transport over MPLS", Mohammed Umair, Kingston Smiler, Donald Eastlake, Lucy Yong, 2015-07-06, This document specifies how to interconnect Transparent Interconnection of Lots of links (TRILL) sites belonging to a tenant that are separated geographically over an MPLS domain. This draft addresses two problems 1) Providing connection between more than two TRILL sites that are separated by an MPLS provider network using [RFC7173] 2) Providing connection between TRILL sites belonging to a tenant over a MPLS provider network "Deployment of Control-/Data-Plane separation in DMM", Fabio Giust, Marco Liebsch, 2015-07-06, The DMM working group is currently looking at solutions for mobility management based on control and data plane separation. In this context, the network entities in charge for the mobility control function are separated from the data plane nodes, responsible mainly for, but not limited to, data packet forwarding. This vision allows for the design of different interaction methods between the mobility control function and the data plane nodes. One of such mechanisms being currently discussed devises an SDN-based abstraction layer between control and data planes, embodied by an SDN Network Controller. This latter interfaces to the mobility control function through a north-bound interface (NBI), and programs the underneath infrastructure through a south-bound interface (SBI), e.g., OpenFlow. This draft describes multiple deployment scenarios for NBI and SBI interworking, given that multiple network controllers could be deployed in order to meet performance requirements e.g., related to latency. "Example Packets for the Minimal 6TiSCH Configuration", Jonathan Munoz, Guillaume Gaillard, Dominique Barthel, 2015-07-06, This draft contains example packets exchanged by nodes implementing draft-ietf-6tisch-minimal. All packets are presented both in raw binary and fully parsed contents. This document can be used as a reference when implementing draft-ietf-6tisch-minimal. "IPv6 IPVPN Option (IPv6VPNO)", Olivier Vandezande, 2015-07-06, In new generation IP networks, where virtualization is highly used, an IPVPN identifier (environment) associated to the target node IP address is needed to deliver the IP packet in the right environment. IPVPN support brings some complexity in the IP networks (e.g. routing protocols, tunneling techniques, etc). Associating the IPVPN information natively in IPv6 with the destination IP address using an IPv6 destination option simplifies IPVPN support. This draft describes the IPv6 IPVPN Destination Option Type and how it is used by IPv6 IPVPN capable nodes. "OmniBroker Publication Protocol", Phillip Hallam-Baker, 2015-07-06, OmniPublish is a Web Service that supports server configuration management. The supported transaction set allows a server to obtain and renew necessary cryptographic credentials, publish service discovery statements and obtain network configuration specifications. "Mesh Link Establishment", Richard Kelsey, 2015-07-06, This document defines the mesh link establishment (MLE) protocol for establishing and configuring secure radio links in IEEE 802.15.4 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop mesh networks by adding three capabilities: 1) dynamically configuring and securing radio links, 2) enabling network-wide changes to radio parameters, and 3) determining link quality prior to link configuration MLE operates below the routing layer, insulating it from the details of configuring, securing, and maintaining individual radio links within a larger mesh network. "Public Safety Use Case", Akbar Rahman, Chonggang Wang, Vinod Choyi, 2015-07-06, A public safety use case is proposed for consideration by the ACE WG. "Delay Tolerant Network (DTN) Numeric Node IDs", Fred Templin, Scott Burleigh, 2015-07-06, The Delay Tolerant Network (DTN) Bundle Protocol (BP) uses Uniform Resource Identifiers (URIs) as the basis for Endpoint and Node IDs. IDs that are encoded as alphanumeric strings can consume excessive precious bandwidth in some instances, leading to a desire for a short numeric ID format. This document discusses alternatives for a DTN numeric node ID format. "Anycast Segments in MPLS based SPRING", P. Sarkar, Hannes Gredler, 2015-07-06, Instead of forwarding to a specific device or to all devices in a group, anycast addresses, let network devices forward a packet to (or steer it through) one or more topologically nearest devices in a specific group of network devices. [I-D.ietf-spring-segment-routing] extended the use of anycast addresses to a SPRING network, wherein a group of SPRING-capable devices can represent a anycast address, by having the same SRGB label block provisioned on all the devices and each one of them advertising the same anycast prefix segment (or Anycast SID). This document describes a proposal for implementing anycast prefix segments in SPRING, without the need to have the same SRGB block (label ranges) provisioned across all the member devices in the group. Each node can be provisioned with a separate SRGB from the label range supported by the specfic hardware platform. "The YANG Package Statement", Andy Bierman, 2015-07-06, This document describes mechanisms for defining a conceptual collection of YANG modules and protocol capability URIs, called a YANG package. Typically, modules with high cohesion that are designed to be used together to manage a service or product feature are included in a YANG package. The purpose of the package is not constrained by this document. For example, a YANG package may describe conformance requirements or simply describe the modules and protocol capabilities implemented in a specific platform. "Sending Solicited RAs Unicast", Andrew Yourtchenko, Lorenzo Colitti, 2015-07-06, On links with a large number of mobile devices, sending Solicited Router Advertisement as multicast packets can severely impact host power consumption. This document recommends that on such network, RAs be sent unicast. "Dynamic Service Path Selection over Multiple Links between SFF and SF for Enhancing Service Stability", th.kang@kt.com, youngtae.han@kt.com, Sungsu Kim, EunKyoung Paik, Namgon Kim, 2015-07-06, In this document, we use SF classification of 1)indispensible SF for packet delivery, allegedly mandatory SFs, such as NAT and 2)optional SFs that a packet can be delivered without them, such as Firewall and IDS. The nodes of SFC-enabled domain can be various. Different vendors make different types of equipments, and this causes performance issues. Considering this diversity, the kind of SFs can be in myriad form. Thus, we should distinguish some mandatory SFs from not mandatory SFs and treat distinctively. Mandatory SFs should be matched with higher-performance SFF to achieve high availability as well as lower the probability of failure. Above all, whether each SF is mandatory or optional should be registered in advance. Mandatory SFs are to allocated to relatively higher-performance, larger capacity, more stable SFFs. SFC constructed using this way of allocation becomes the path for packets and packets are transferred to classifier through C1 interface, and to SFF through C2 interface, respectively. "Overlay for discovery in a BIER network", Anish Peter, Robert Kebler, Vikram Nagarajan, 2015-07-06, This document introduces an overlay model for signaling egress interest to the ingress BIER router. "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Behcet Sarikaya, Frank Xia, Pascal Thubert, 2015-07-06, This document defines an extension of 6LoWPAN Neighbor Discovery for application in low-power and lossy networks. The protocol is specified to be protected and to support multi-hop operation. A node computes its Cryptographic, Unique Interface ID, and associates one or more of its Registered Addresses with that Cryptographic ID in place of the EUI-64 that is used in RFC 6775 to uniquely identify the interface of the Registered Address. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the state in the 6LR and 6LBR regarding the Registered Address. "WebRTC Use Case and Framework for Privacy Enhanced RTP Conferencing (PERC)", Magnus Westerlund, John Mattsson, 2015-07-06, The work so far on Privacy Enhanced RTP Conferencing, which allows end-to-end security also in centralized switch RTP based conference, has not considered WebRTC in detail. This document looks at the use case of WebRTC based endpoints, it also considers implications of using external providers for both conference applications and centralized media distribution devices. From this a number of challenges have been determined, and requirements are derived from these. Finally the draft presents some straw man for possible solutions. "Interface VLAN YANG Data Models", Robert Wilton, David Ball, Tapraj Singh, Selvakumar Sivaraj, 2015-07-06, This document defines YANG models to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. Primarily the classification is based on VLAN identifiers in the 802.1Q VLAN tags, but the model also has support for matching on some other layer 2 frame header fields and is designed to be easily extensible to match on other arbitrary header fields. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of a 802.1Q VLAN bridge. "Multicast Security for the Lighting Domain", Abhinav Somaraju, Sandeep Kumar, Hannes Tschofenig, 2015-07-06, Lighting systems have strict requirements on message latency and synchronization (typically latency less than 200 ms and jitter less than 50 ms). There are several lighting use cases that require securing such communication between a (group of) senders and a group of receivers. This draft describes initial ideas for authorization and key management required for the secure group communication within a lighting system. "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)", Alan Johnston, Bernard Aboba, Andrew Hutton, Laura Liess, Thomas, 2015-07-06, Opportunistic Secure Real-time Transport Protocol (OSRTP) allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP is an implementation of Opportunistic Security, as defined in RFC 7435. OSRTP does not require advanced SDP extensions or features and is fully backwards compatible with existing secure and insecure implementations. OSRTP is not specific to any key management technique for SRTP. "Two-Way Active Measurement Protocol (TWAMP) Light Data Model", Greg Mirsky, Tamas Elteto, 2015-07-06, This document specifies the data model for implementations of Session-Sender and Session-Reflector for Two-Way Active Measurement Protocol (TWAMP) Light mode using YANG. "Gap Analysis on Network Virtualization Activities", Carlos Bernardos, Akbar Rahman, Juan-Carlos Zúñiga, Luis Contreras, Pedro Aranda, 2015-07-06, Network Function Virtualization (NFV) and Software Defined Networking (SDN) are changing the way the telecommunications sector will deploy, extend and operate their networks. These new technologies aim at reducing the overall costs by outsourcing communication services from specific hardware in the operators' core to server farms scattered in datacenters (i.e. compute and storage virtualization). In addition, the connecting networks are fundamentally affected in they way they route, process and control traffic(i.e. network virtualization). Virtualization is becoming a trend which is being adopted in many scenarios for different purposes. This document overviews existing efforts around virtualization at the IETF/IRTF, focusing on those related to NFV and SDN. These efforts are mapped to the most relevant architectures being defined outside IETF, namely at the ETSI NFV ISG, the ETSI MEC ISG and the ONF. The main goal of this document is to serve as a survey of the different efforts that have been taken and are currently taking place at IETF and IRTF in regards to network virtualization, putting them into context considering efforts by other SDOs, and identifying current gaps that can be tackled at IETF or researched at the IRTF. "Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Virtual Router Redundancy Protocol (VRRP) Use Case", Greg Mirsky, Jeff Tantsura, 2015-07-06, This document discusses use of Bidirectional Forwarding Detection (BFD) for multi-point networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second Master convergence. "IS-IS LSP lifetime corruption - Problem Statement", Bruno Decraene, Christof Schmitz, 2015-07-06, The IS-IS protocol exchanges Link State Packet (LSP) to exchange routing information. The lifetime of this LSP is located in the LSP header and is neither protected from corruption by the Fletcher checksum nor by cryptographic authentication. So the LSP lifetime may be altered, either accidentally or maliciously any time. The lifetime field of the LSP is an important field for the correct operation of IS-IS. Corruption of this LSP lifetime may cause flooding storm with severe impact in the network. This draft documents the problem statement and calls for a solution. "Screencasting Considerations and L1-Tree Wavelet Coding", Jean-Marc Valin, 2015-07-06, This document proposes a screencasting encoding mode based on the Haar wavelet transform and L1-tree wavelet (L1TW) coding. "I2RS Environment Security Requirements", Daniel Migault, Joel Halpern, Susan Hares, 2015-07-06, 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 described in [I-D.hares-i2rs-auth-trans]. The reason to have separate document is that protocol security requirements are intended to help the design of the I2RS protocol. "IANA Registry for 6lowpan Additional Dispatch Bytes", Samita Chakrabarti, Gabriel Montenegro, Ralph Droms, james, 2015-07-06, RFC4944 defines ESC dispatch type for additional dispatch bytes in the 6lowpan header. The value of ESC byte has been updated by RFC6282. However, the usage of ESC extension bytes has not been defined in RFC6282 and RFC4944. The purpose of this document is to define the usage of ESC extension bytes. It also records the initial values for extended dispatch values and requests corresponding IANA actions. "Comments on Data Organization and Operational State", Martin Bjorklund, Andy Bierman, Jürgen Schönwälder, Kent Watsen, 2015-07-06, This document is a reply to OpenConfig's proposed solutions to some common data modeling problems. "Advertising L2 Bundle Member Link Attributes in IS-IS", Les Ginsberg, Ahmed Bashandy, Clarence Filsfils, Stefano Previdi, Mohan Nanduri, Ebben Aries, 2015-07-06, This document introduces the ability for IS-IS to advertise the link attributes of layer 2 (L2) bundle members. "Private Media Requirements in Privacy Enhanced RTP Conferencing", Paul Jones, Nermeen Ismail, David Benham, Nathan Buckles, John Mattsson, Richard Barnes, 2015-07-06, This document specifies the requirements for ensuring the privacy and integrity of real-time transport protocol (RTP) media flows between two or more endpoints communicating through one or more centrally located media distribution devices (MDDs). "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing", Paul Jones, Nermeen Ismail, David Benham, 2015-07-06, This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distribution devices are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). "LISP support for Multi-Tuple EIDs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, sbarkai@gmail.com, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci, 2015-07-06, This document describes extensions for LISP to support EIDs based on tuples of multiple elements. "Thor Video Codec", Arild Fuldseth, Gisle Bjontegaard, Mo Zanaty, 2015-07-06, This document provides a high-level description of the Thor video codec. Thor is designed to achieve high compression efficiency with moderate complexity, using the well-known hybrid video coding approach of motion-compensated prediction and transform coding. "Supporting long TCP options in Multipath TCP", Olivier Bonaventure, 2015-07-06, The extensibility of TCP is severely limited by the Data Offset field of the TCP header that limits the number of bytes that can be used in each segment to transport options. This document considers Multipath TCP as the starting point and analyses different alternatives to improve the ability of Multipath TCP to transport TCP extensions. "Include Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Ori Gerstel, Kenji Kumaki, Ruediger Kunze, 2015-07-06, There are scenarios that require two or more LSPs or segments of LSPs to follow same route in the network. This document specifies methods to communicate route inclusions along the loose hops during path setup using the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) protocol. "Guidelines for DiffServ to IEEE 802.11e Mapping", Tim Szigeti, Fred Baker, 2015-07-06, As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF offers design recommendations for wired IP networks, while a separate and autonomous standards-body, the IEEE, administers the standards for wireless 802.11e networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11e User Priority (UP) mappings to reconcile the design recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS. "Experience and Evaluation of the Distributed Node Consensus Protocol", Kaiwen Jin, Pierre Pfister, Jiazi Yi, 2015-07-06, The Distributed Node Consensus Protocol (DNCP) is a generic state synchronization protocol that offers data synchronization and dynamic network topology discovery within a network. This document reports experience with the DNCP, which includes its implementation status and performance evaluation in a simulated environment. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Signaling Objective Function and Metric Bound", Zafar Ali, George Swallow, Clarence Filsfils, Luyuan Fang, Kenji Kumaki, Ruediger Kunze, Daniele Ceccarelli, Xian Zhang, 2015-07-06, In particular networks such as those used by financial institutions, network performance criteria such as latency are becoming critical to data path selection. However cost is still an important consideration. This leads to a situation where path calculation involves multiple metrics and more complex objective functions. When using GMPLS control plane, there are many scenarios in which a node may need to request a remote node to perform path computation or expansion, like for example multi-domain LSP setup, Generalized Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) or simply the utilization of a loose ERO in intra domain signaling. In such cases, the node requesting the setup of an LSP needs to convey the required objective function to the remote node, to enable it to perform route computation in the desired fashion. Similarly, there are cases where the ingress node needs to indicate a TE metric bound for a loose segment that is expanded by a remote node. This document defines extensions to the RSVP-TE Protocol to allow an ingress node to request the required objective function for the route computation, as well as a metric bound to influence route computation decisions at a remote node(s). ID draft-ali-teas-rc-objective-function-metric-bound-00.txt "Recursive orchestration of federated virtual network functions", Gino Carrozzo, Kostas Pentikousis, 2015-07-06, This document introduces a policy-based resource management and orchestration framework which aims at contributing towards the current namesake NFVRG near-term work items. It describes key points of the recursive resource orchestration framework developed within the wider research area of federated virtual network function orchestration. The document also relates this effort with respect to other orchestration frameworks, thus addressing both the NFV research and practitioner communities. "Multicast Wifi Problem Statement", Charles Perkins, Mike McBride, 2015-07-06, There have been known issues with IP Multicast, in an 802.11 environment, which have prevented the deployment of multicast in these wifi environments. The mboned working group would like to gather the problems of wifi multicast into one problem statement document so as to offer the community guidance on current limitations. "SACM ECP Mapping", Chris Coffin, Daniel Haynes, Charles Schmidt, Jessica Fitzgerald-McKay, 2015-07-06, This document builds upon [I-D.fitzgeraldmckay-sacm-endpointcompliance] to demonstrate how published IETF, ISO, and TCG standards, available today, can be used to accomplish the use cases outlined in [I-D.ietf-sacm-use-cases]. "Requirements for the design of a Substrate Protocol for User Datagrams (SPUD)", Brian Trammell, Mirja Kuehlewind, 2015-07-06, The Substrate Protocol for User Datagrams (SPUD) BoF session at the IETF 92 meeting in Dallas in March 2015 identified the potential need for a UDP-based encapsulation protocol to allow explicit cooperation with middleboxes while using new, encrypted transport protocols. This document proposes an initial set of requirements for such a protocol, and discusses tradeoffs to be made in further refining these requirements. "Approaches to HTTPS-based Request Routing and Delegation", Sergey Slovetskiy, 2015-07-06, This document provides a basic non exhaustive background and discusses potential approaches to the issue of correct delegation of the encrypted (TLS-based) traffic requests between CDNs in inter CDN networks and during interactions between client UAs, CSPs, and CDNs. "Collaborative Interface between Network Operators and CDNs", Luis Contreras, 2015-07-06, The absence of appropriate mechanisms for information exchange between Network Operators and Content Delivery Networks (CDNs) and content providers leads to avoidable inefficiency for the delivery of contents to end users in situations like congestion, selection of best distributed delivery end point, etc. This document describes the need of an information exchange interface between Network Operators and CDNs to collaborate in order to provide the best service quality to the end users. "Elastic ICN Packet Format", Ravi Ravindran, Asit Chakraborti, 2015-07-06, This draft proposes a new packet format motivated with the goal of having a single protocol for constrained IoT and unconstrained infrastructure segments of an ICN network. The packet format focuses on reducing the transport overhead compared to the one proposed in [1]. The resulting savings in terms of energy and computing is significant for low power radios with restricted payload size. "Support for Notifications in CCN", Ravi Ravindran, Asit Chakraborti, marc.mosko@parc.com, Ignacio Solis, 2015-07-06, This draft proposes a new packet primitive called Notification for CCN. Notification is a PUSH primitive and can be unicast or multicast to multiple listening points. Notifications do not expect a Content Object response hence only requires the use of FIB state in the CCN forwarder. Emulating Notification as a PULL has performance and forwarding implications. The draft proposes a new fixed header primitive called Notification and a CCN message encoding using Content Object primitive to transport Notifications. These discussions are presented in the context of CCNx1.0 [1] proposal. "Session Key Interface (SKI) for TLS and DTLS", Kelsey Cairns, John Mattsson, Robert Skog, 2015-07-06, This document describes a session key interface that can be used for TLS and DTLS. The Heartbleed attack has clearly illustrated the security problems with storing private keys in the memory of the TLS server. Hardware Security Modules (HSM) offer better protection but are inflexible, especially as more (D)TLS servers are running on virtualized servers in data centers. "LISP Hybrid Access", Michael Menth, Andreas Stockmayer, Mark Schmidt, 2015-07-06, Hybrid access (HA) allows simultaneous usage of multiple access links. Advantages are increased bandwidth and improved resilience. This document presents LISP Hybrid Access (LISP-HA), a mechanism to provide HA based on LISP technology. The document discusses potential changes needed to perform dynamic load-balancing and per packet load-balancing, which both increase the efficiency of HA. To that end, modified usage of some fields in the LISP header is proposed. Discussed use cases include the bundling of multiple access technologies for mobile devices and residential access routers. Additionally, we provide some considerations how LISP-HA can be deployed by providers. "Concepts for Domain Name Relationships", Casey Deccio, John Levine, 2015-07-06, Various Internet protocols and applications require some mechanism for identifying relationships between Domain Name System (DNS) names. In this document we provide examples of protocols and applications for which knowledge of these relationships is useful, if not required. Further we discuss the various types of domain name relationships, review current needs and solutions, and identify considerations for solution sets. "LISP Map Server Reliable Transport", Christian Cassar, Isidor Kouvelas, Darrel Lewis, Jesus Arango, Johnson Leong, 2015-07-06, The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. This document has been renamed to avoid ambiguity. It is an update to [I-D.kouvelas-lisp-reliable-transport]. "SMTP and SUBMISSION Service Extensions For Address Query", Keith Moore, Chris Newman, 2015-07-06, This document defines several mechanisms which can be used by a client such as a Mail User Agent or Mail Submission Agent, to query an SMTP server which is configured to accept incoming mail for a mail domain, to obtain information associated with an email address based in that domain. Among other purposes, these mechanisms are intended to facilitate discovery of senders' and/or recipients' public keys for use in automatic verification of whole-message digital signatures and automatic whole-message encryption of email sent to recipients. "Overlapped Block Motion Compensation for NETVC", Timothy Terriberry, 2015-07-06, This document proposes a scheme for overlapped block motion compensation that could be incorporated into a next-generation video codec. The scheme described is that currently used by Xiph's Daala project, which supports variable block sizes without introducing any discontinuities at block boundaries. This makes the scheme suitable for use with lapped transforms or other techniques where encoding such discontinuities is expensive. "Uplink access technology indications in Router Advertisements", Suresh Krishnan, 2015-07-06, In IPv6 networks Router Advertisements can be used for providing common configuration information to nodes that are attached. There are some scenarios where it is advantageous for routers to provide their uplink access technology information to attached hosts. This document describes a neighbor discovery option that will allow the routers to do so. "IP over Intentionally Partially Partitioned Links", Erik Nordmark, 2015-07-06, 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. "Service Chaining using Virtual Networks with BGP", Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, 2015-07-06, 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. "Time Domain Lapped Transforms for Video Coding", Nathan Egge, Timothy Terriberry, 2015-07-06, This proposes the use of Time Domain Lapped Transforms (TDLT) as the transform step for video coding. "Examples for Using DCAF with less constrained devices", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, 2015-07-06, Constrained nodes are devices which are limited in terms of processing power, memory, non-volatile storage and transmission capacity. Due to these constraints, commonly used security protocols are not easily applicable. Nevertheless, an authentication and authorization solution is needed to ensure the security of these devices. The Delegated CoAP Authorization Framework (DCAF) specifies how resource-constrained nodes can delegate defined authentication- and authorization-related tasks to less-constrained devices called Authorization Managers, thus limiting the hardware requirements of the security solution for the constrained devices. To realize the vision of "one Internet for all", constrained devices need to securely establish trust relationships with less constrained devices. This document lists examples for using DCAF with less constrained devices. "Application Bridging for Federated Access Beyond web (ABFAB) Credential Forwarding and Delegation", S. Paetow, 2015-07-06, A core use case of ABFAB-based authentication is access to remote systems. In this and other use cases it is preferable that the same identity initially used to gain access to the remote system is used for further authentication sessions from the initial system onwards. The current architecture and UI considerations require the use of secure storage local to the system for any identities from that system onwards. This document aims to explore alternate proposals for the reuse of an identity configured on the initial ABFAB-enabled client device by the use of credential forwarding or delegation in a similar fashion to those used by other GSS-API mechanisms. "IS-IS Point-to-Multipoint operation", C. Franke, David Lamparter, 2015-07-06, This document describes a new mode operation for IS-IS. In addition to the existing LAN and point-to-point modes of operation, a point- to-multipoint mode is defined. This mode is useful for operation both on networks with more than two routers where multicast is expensive in comparison to unicast, as well on networks where creating a LAN pseudonode cannot adequately reflect metrics. "ALTO Extension: A Routing State Abstraction Service Using Declarative Equivalence", Kai Gao, Xing Wang, Yang Yang, Guohai Chen, 2015-07-06, The Application-Layer Traffic Optimization (ALTO) protocol has defined multiple services (e.g., network maps, cost maps, filtered maps, the endpoint cost service, and the endpoint property service) to provide network state information to network applications. In a higher-level view, both the cost maps and the endpoint cost service can be considered as providing views into the routing state of a network (i.e., the path properties). A drawback of these existing services, however, is that they are static, application-oblivious views, without guidance from network applications. This document designs a new ALTO service named Routing State Abstraction using Declarative Equivalence (RSADE). Allowing applications to provide declarative guidance on the intended use of the network routing state, RSADE allows a network to compute compact, customized routing state abstraction beyond the existing services. "Proposal for Fixing ICE", Cullen Jennings, 2015-07-06, This draft raises some issues and proposes some directions for improving ICE. It is never meant to become an RFC but is for WG discussion. "Forcerenew Reconfiguration Extensions for DHCPv4", Luyuan Fang, Deepak Bansal, Fabio Chiussi, 2015-07-06, This document extends the definition of the FORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the FORCERENEW 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. "Deployment Models for Distributed Mobility Management", Seil Jeon, Young-Han Kim, 2015-07-06, This document briefly presents available deployment models for distributed mobility management networks, being consisted of mobility management functions: anchoring function, location management, and forwarding management functions defined in RFC7429. Some of the functions are modified on a need to allow potential deployment scenarios support. "DNCP Use Case in a Distributed Cache System", Aloys Augustin, 2015-07-06, In a distributed cache system, at some point the nodes need to share and synchronise some information. This document explains how this cache system works and shows how DNCP is useful in this situation. "ECA Policy YANG Data Model", Maoke Chen, Luis Contreras, 2015-07-06, This document describes a YANG data model for SUPA (Simplified Use of Policy Abstractions) ECA (Event-Condition-Action) policies using policy abstractions defined in [I-D. strassner-supa-generic- policy-info-model]. The EPDM (ECA policy data model) is refined from SGPIM and EPRIM to be applied to deliver various management policies for controlling managed entities throughout the service development and deployment lifecycle. The core data model could be augmented by additional YANG data modules modeling and configuring policy-related protocols and functions. Reusability as the major advantage of this approach can be realized by metadata. The policy data model described in this document provides common building blocks for such extensions. "Mobile LMAP Use Cases", Antonio Bovo, Roger, 2015-07-06, This document discusses the use cases for broadband measurements applied to the mobile domain as an adjunct to such scenarios for the fixed broadband domain. The specifics related to the mobile domain are discussed considering them as possible extensions of IETF LMAP measurements. "Signaling Maximum SID Depth using Border Gateway Protocol Link-State", Jeff Tantsura, Greg Mirsky, 2015-07-06, This document discusses use of BGP-LS to expose node and/or link on a node MSD "Maximum SID Depth" to a centralized controller (PCE/SDN). "An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol Diet Exchange (HIP DEX)", Yoshihiro Ohba, 2015-07-06, This document defines an extension of MLE (Mesh Link Establishment) protocol to encapsulate HIP DEX key exchange protocol messages. "HTTPS and delegation of encrypted traffic between interconnected CDNs", Frederic Fieau, Iuniana Oprescu, 2015-07-06, This document illustrates some use cases and associated problems related to delivery of HTTPS secured traffic in the context of interconnected CDNs. A common scenario is when a uCDN is delegating the delivery of encrypted traffic to a dCDN using HTTP or DNS redirection. Some potential solutions are considered. "A Yang model for I2RS service topology", Susan Hares, Linda Dunbar, 2015-07-06, This document defines I2RS protocol-independent service layer virtual topology data model. This data model utilizes the concepts in the generic I2RS topology model of virtual networks (node, links, termination points) and cross-layer topologies. This virtual service topology may be a composite layer created from the combination of protocol-dependent service layers. Protocol-dependent services layers include: L3VPN, L2VPN, EVPN, E-Tree, and others. "MPLS Label Forwarding with No Swapping", Luyuan Fang, Fabio Chiussi, Barak Gafni, 2015-07-06, This document defines MPLS label forwarding operation with no label swapping as a new MPLS label operation extension to the existing basic forwarding operation of label push, pop, and swap. "Subscription-Less Web Push Framework", Fabio Chiussi, 2015-07-06, Subscription is a integral part of the current Web Push service. This document describes a framework for making subscription more flexible to accommodate a number of use cases for Web Push. "Considerations for the use of TEAS TE topology model in multi layer applications", Paul Doolan, Jonathan Sadler, 2015-07-06, This document briefly describes an important inter layer use case for TE topology information and considers requirements and operational considerations the derive from it. "Resource Model Indication with CoAP", JinHyeock Choi, Gabor Bajko, Darshak Thakore, 2015-07-06, There is much interest in "Internet of Things (IoT)" and multiple standards following the REST architectural style are under development. In a RESTful interaction, IoT devices need to understand each other's resource representations, both the semantic meaning and the syntactic form, to interact properly. For interoperability among different standards, it is helpful for CoAP endpoints to indicate the resource models they support. This document presents a scheme for IoT devices to exchange their resource model information and requests from IANA new Internet media types and CoAP Content-Format identifier for resource model indication. "Analysis of the SFC scalability", Ting Ao, 2015-07-07, SFC as a chain of a set of service function, should be scalable to meet all kinds of requirements. The scalability of SFC means the SFC could be elastic to accomodate one or more SFs join the SFC , or leave the SFC. The document present four cases of the scalability, and analysis the data plane and the control plane to implement the scalable SFC. "Design and Implementation of Large Data Transfer Coordinator", xinwang2014@hotmail.com, Shu Dong, Guohai Chen, 2015-07-07, The Application-Layer Traffic Optimization (ALTO) protocol provides network information with the goal of improving both application performance and network resource utilization. As data transfers become larger (e.g., due to big data analysis), more data transfers are concurrent but with service requirements, and more network capabilities are emerging (e.g., SDN allowing a data transfer to request specific routes or Qos), the management of large data transfers has become an increasingly challenging issue. This document introduces Data Transfer Center (DTC), a centralized framework to coordinate and schedule large data transfers. DTC considers all three components: data transfer requirements, (ALTO) network information, and SDN control capabilities. This document specifies not only the basic framework of DTC, but also a key component, Data Transfer Set (DTS) to specify data transfers and their relations. "Using IPID for Performance Monitoring in VxLAN Network", Hao Chen, Li Yizhou, 2015-07-08, IP Identification(IPID)is a field in IP header primarily used to uniquely identify the group of fragments of a single IP packet. The value of IPID field in a packet from a specific traffic flow or source IP address keeps increasing until wrapped-around. This document specifies a method by carefully examining IPID value to monitor the performance of VXLAN network. In this memo packet loss measurement is mainly considered. This method requires no extra hardware support, which means it is compatible with most of the deployed routers or switches. Such a mechanism is applicable to IPv4 network and potential useful in overlay network with different data encapsulation. "Diameter of Things (DoT): A Protocol for real-time Telemetry of IoT Applications", Soheil, Schahram Dustdar, Negar Behinaein, Rabee Rahimzadeh, 2015-07-09, The Diameter of Things (DoT) protocol is intended to provide a realtime telemetry framework for IoT applications in resource-constraint gateways. Such metering capability is needed when lack of resources among competing applications dictates our schedule and credit allocation. The DoT protocol can be incorporated to implement real-time AAA of IoT services for prepaid subscribers. The DoT employs mechanisms to meter the IoT composite application units used/charged over a client credit. Such metering methods come in two models of session-based and event-based patterns. The former is used for scenarios where the charged units are continuously consumed while the latter is typically used when units are implicit invocation events. "Analysis of Existing work for I2NSF", Susan Hares, Dacheng Zhang, Robert Moskowitz, Hosnieh Rafiee, 2015-07-10, This document analyzes the status of the arts 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. "DDoS Open Threat Signaling Requirements", Andrew Mortensen, 2015-07-13, This document discusses the requirements for a protocol sufficient for the goals of the DDoS Open Threat Signaling (DOTS) Working Group. Network Time Protocol (ntp) --------------------------- "Network Time Security", Dieter Sibold, Stephen Roettger, Kristof Teichel, 2015-07-06, This document describes Network Time Security (NTS), a collection of measures that enable secure time synchronization with time servers using protocols like the Network Time Protocol (NTP) or the Precision Time Protocol (PTP). Its design considers the special requirements of precise timekeeping which are described in Security Requirements of Time Protocols in Packet Switched Networks [RFC7384]. "The Network Time Protocol Version 4 (NTPv4) Extension Fields", Tal Mizrahi, Danny Mayer, 2015-06-28, The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field, defined in RFC5905, is an optional field that resides at the end of the NTP header, and can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MAC). "Using UDP Checksum Trailers in the Network Time Protocol (NTP)", Tal Mizrahi, 2015-01-15, The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To faciliate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP checksum field. The behavior defined in this document is interoperable with existing NTP implementations. "Protecting Network Time Security Messages with the Cryptographic Message Syntax (CMS)", Dieter Sibold, Kristof Teichel, Stephen Roettger, Russ Housley, 2015-07-06, This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect the messages in the Network Time Security (NTS) protocol. NTS provides authentication of time servers as well as integrity protection of time synchronization messages using Network Time Protocol (NTP) or Precision Time Protocol (PTP). "Using the Network Time Security Specification to Secure the Network Time Protocol", Dieter Sibold, Stephen Roettger, Kristof Teichel, 2015-07-06, This document describes how to use the measures described in the Network Time Security (NTS) specification to secure time synchronization with servers using the Network Time Protocol (NTP). Network Virtualization Overlays (nvo3) -------------------------------------- "Use Cases for Data Center Network Virtualization Overlays", Lucy Yong, Mehmet Toy, Aldrin Isaac, Vishwas Manral, Linda Dunbar, 2015-02-05, This document describes Data Center (DC) Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve to different applications. "Network Virtualization NVE to NVA Control Protocol Requirements", Lawrence Kreeger, Dinesh Dutt, Thomas Narten, David Black, 2015-07-02, [RFC7364] "Problem Statement: Overlays for Network Virtualization" discusses the needs for network virtualization using overlay networks in highly virtualized data centers. The problem statement outlines a need for control protocols to facilitate running these overlay networks. This document outlines the high level requirements to be fulfilled by the control protocols related to building and managing the mapping tables and other state information used by the Network Virtualization Edge to transmit encapsulated packets across the underlying network. "Security Requirements of NVO3", Sam Hartman, Dacheng Zhang, Margaret Wasserman, Zu Qiang, Mingui Zhang, 2015-06-18, The draft describes a list of essential requirements in order to benefit the design of NVO3 security solutions. In addition, this draft introduces the candidate techniques which could be used to construct a security solution fulfilling these security requirements. "An Architecture for Overlay Networks (NVO3)", David Black, Jon Hudson, Lawrence Kreeger, Marc Lasserre, Thomas Narten, 2015-03-09, This document presents a high-level overview architecture for building overlay networks in NVO3. The architecture is given at a high-level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently and with clear interfaces and interactions with other components. It should be possible to build and implement individual components in isolation and have them work with other components with no changes to other components. That way implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components. "Hypervisor to NVE Control Plane Requirements", Li Yizhou, Lucy Yong, Lawrence Kreeger, Thomas Narten, David Black, 2015-02-09, In a Split-NVE architructure, the functions of the NVE are split across the hypervisor/container on a server and an external network equipment which is called an external NVE. A control plane protocol(s) between a hypervisor and its associated external NVE(s) is used for the hypervisor to distribute its virtual machine networking state to the external NVE(s) for further handling. This document illustrates the functionality required by this type of control plane signaling protocol and outlines the high level requirements. Virtual machine states as well as state transitioning are summarized to help clarifying the needed protocol requirements. "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2015-06-24, This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of arbitrary IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. "Generic Protocol Extension for VXLAN", Paul Quinn, Rajeev Manur, Lawrence Kreeger, Darrel Lewis, Fabio Maino, Michael Smith, Puneet Agarwal, Lucy Yong, Xiaohu Xu, Uri Elzur, Pankaj Garg, David Melman, 2015-05-01, This draft describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with three new capabilities: support for multi-protocol encapsulation, operations, administration and management (OAM) signaling and explicit versioning. "Geneve: Generic Network Virtualization Encapsulation", Jesse Gross, T. Sridhar, Pankaj Garg, Chris Wright, Ilango Ganga, Puneet Agarwal, Kenneth Duda, Dinesh Dutt, Jon Hudson, 2015-05-08, Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements in the system, the requirements on tunnels are influenced by all of these components. Flexibility is therefore the most important aspect of a tunnel protocol if it is to keep pace with the evolution of the system. This draft describes Geneve, a protocol designed to recognize and accommodate these changing capabilities and needs. "A Framework for Multicast in NVO3", Anoop Ghanwani, Linda Dunbar, Mike McBride, Vinay Bannai, Ram (Ramki) Krishnan, 2015-05-11, This document discusses a framework for supporting multicast traffic in a network that uses Network Virtualization using Overlays over Layer 3 (NVO3). Both infrastructure multicast and application- specific multicast are discussed. It describes the various mechanisms and considerations that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms. Web Authorization Protocol (oauth) ---------------------------------- "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Phil Hunt, Justin Richer, William Mills, Prateek Mishra, Hannes Tschofenig, 2015-07-06, The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution", J. Bradley, Phil Hunt, Michael Jones, Hannes Tschofenig, 2015-03-05, RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. This document describes how the client obtains this keying material from the authorization server. "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", Michael Jones, J. Bradley, Hannes Tschofenig, 2015-07-06, This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. "A Method for Signing an HTTP Requests for OAuth", Justin Richer, J. Bradley, Hannes Tschofenig, 2015-03-09, This document a method for offering data origin authentication and integrity protection of HTTP requests. To convey the relevant data items in the request a JSON-based encapsulation is used and the JSON Web Signature (JWS) technique is re-used. JWS offers integrity protection using symmetric as well as asymmetric cryptography. "OAuth 2.0 Token Exchange", Michael Jones, Anthony Nadalin, 2015-07-06, This specification defines how to request and obtain Security Tokens from OAuth Authorization Servers, including enabling one party to act on behalf of another or enabling one party to delegate authority to another. "Request by JWS ver.1.0 for OAuth 2.0", Nat Sakimura, J. Bradley, 2015-07-06, The authorization request in OAuth 2.0 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. "Proof Key for Code Exchange by OAuth Public Clients", Nat Sakimura, J. Bradley, Naveen Agarwal, 2015-07-10, OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). "OAuth 2.0 Token Introspection", Justin Richer, 2015-07-03, This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "CAPWAP Extension for 802.11n and Power/channel Autoconfiguration", Yifan Chen, Dapeng Liu, Hui Deng, Lei Zhu, 2015-07-06, The CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. Several new amendments of 802.11 have been published since RFC5416 was published in 2009. 802.11n is one of those amendments and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n and also defines a power and channel auto configuration extension. "Management Information Base for Virtual Machines Controlled by a Hypervisor", Hirochika Asai, Michael MacFaden, Jürgen Schönwälder, Keiichi Shima, Tina Tsou, 2015-05-28, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). "Alternate Tunnel Encapsulation for Data Frames in CAPWAP", Rong Zhang, Zehn Cao, Hui Deng, Rajesh Pazhyannur, Sri Gundavelli, Li Xue, 2015-04-26, Control And Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Further, it may also be desirable to use different tunnel encapsulations to carry the stations' data frames. This document provides a specification for this and refers to it as Alternate tunnel encapsulation. The Alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for Alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported Alternate Tunnel encapsulation types while configuring the WTP. "HMAC-SHA-2 Authentication Protocols in USM for SNMPv3", Johannes Merkle, Manfred Lochter, 2015-04-21, This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Operational Security Considerations for IPv6 Networks", Kiran Chittimaneni, Merike Kaeo, Eric Vyncke, 2015-03-09, Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Fernando Gont, Shucheng LIU, Gunter Van de Velde, 2015-07-06, This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6 Shield. "Network Reconnaissance in IPv6 Networks", Fernando Gont, Tim Chown, 2015-04-30, IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore brute-force IPv6 address scanning attacks have been considered unfeasible. This document updates RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address scanning techniques apply to IPv6 networks, and exploring some additional techniques that can be employed for IPv6 network reconnaissance. In doing so, this document formally obsoletes RFC 5157. "Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers", Fernando Gont, Shucheng LIU, Ron Bonica, 2015-03-22, It is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type, and provides advice on the filtering of IPv6 packets based on the IPv6 Extension Headers and the IPv6 options they contain. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred Baker, 2015-02-17, OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward compatibility mechanisms are also described. "OSPF Extensions for Segment Routing", Peter Psenak, Stefano Previdi, Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, 2015-06-26, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPF extensions required for Segment Routing. "OSPFv2 Prefix/Link Attribute Advertisement", Peter Psenak, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, Acee Lindem, 2015-06-07, OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPF opaque LSAs based on Type- Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Dependent on the application, these prefixes and links may or not be advertised in the fixed-format LSAs. The OSPF opaque LSAs are optional and fully backward compatible. "OSPFv3 Extensions for Segment Routing", Peter Psenak, Stefano Previdi, Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, 2015-06-26, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions that are required for Segment Routing. "OSPF extensions to advertise S-BFD Target Discriminator", Manav Bhatia, Carlos Pignataro, Sam Aldrin, Trilok Ranganath, 2015-03-23, This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the S-BFD discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3. "Carrying Routable IP Addresses in OSPF RI LSA", Xiaohu Xu, Uma Chunduri, Manav Bhatia, 2015-04-14, This document proposes two new TLVs within the body of the OSPF Router Information (RI) Opaque LSA, called Routable IPv4 Address TLV and Routable IPv6 Address TLV. Here the term OSPF means both OSPFv2 and OSPFv3. "Advertising per-node administrative tags in OSPF", Shraddha Hegde, Harish Raghuveer, Hannes Gredler, Rob Shakir, Anton Smirnov, Zhenbin Li, Bruno Decraene, 2015-06-01, This document describes an extension to OSPF protocol [RFC2328] to add an optional operational capability, that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to OSPF protocol [RFC2328] to advertise per-node administrative tags. This optional operational capability allows to express and act upon locally-defined network policy which considers node properties conveyed by tags. Node tags may be used either by OSPF itself or by other applications consuming information propagated via OSPF. This document describes the protocol extensions to disseminate per- node administrative-tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags. "OSPFv3 over IPv4 for IPv6 Transition", Helen Chen, Acee Lindem, R. Atkinson, 2015-05-11, This document defines a mechanism to use IPv4 to transport OSPFv3 packets, in order to facilitate transition from IPv4-only to IPv6 and dual-stack within a routing domain. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. "OSPF Extensions to Support Maximally Redundant Trees", Alia Atlas, Shraddha Hegde, Chris Bowers, Jeff Tantsura, Zhenbin Li, 2015-01-19, This document specifies extensions to OSPF to support the distributed computation of Maximally Redundant Trees (MRT). Some example uses of the MRTs 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 transitioning of capabilities. An extension is introduced to flood MRT-Ineligible links, due to administrative policy. The need for a mechanism to allow routers to advertise a worst-case FIB compute/install time is well understood for controlling convergence. This specification introduces the Controlled Convergence TLV to be carried in the Router Information LSA. "OSPF Two-part Metric", Lili Wang, Acee Lindem, Dave DuBois, Vibhor Julka, Tom McMillan, 2015-01-20, This document specifies an optional extension to the OSPF protocol, to represent the metric on a multi-access network as two parts: the metric from a router to the network, and the metric from the network to the router. The router to router metric would be the sum of the two. "Extensions to OSPF for Advertising Optional Router Capabilities", Acee Lindem, Naiming Shen, JP Vasseur, Rahul Aggarwal, Scott Shaffer, 2015-01-23, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification including support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities. "OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, Alvaro Retana, Ning So, Vic Liu, Mehmet Toy, Lei Liu, 2015-07-02, This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link down inside the zone is not seen by any router outside of the zone. "Yang Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Jeffrey Zhang, Dean Bogdanovic, Kiran Sreenivasa, 2015-07-06, This document defines a YANG data model that can be used to configure and manage OSPF. "Signaling Entropy Label Capability Using OSPF", Xiaohu Xu, Sriganesh Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2015-04-20, Multi Protocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it can process ELs on that tunnel. This draft defines a mechanism to signal that capability using OSPF. This mechanism is useful when the label advertisement is also done via OSPF. "OSPF Extensions for Flow Specification", Qiandeng Liang, Jianjie You, Nan Wu, Peng Fan, Keyur Patel, Acee Lindem, 2015-06-21, Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., OSPF), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes. This document discusses the use cases for distributing flow specification (FlowSpec) routes using OSPF. Furthermore, this document defines a OSPF FlowSpec Opaque Link State Advertisement (LSA) encoding format that can be used to distribute FlowSpec routes, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins, 2015-05-08, This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol and SIP usage ([RFC6940], [I-D.ietf-p2psip-sip]) defined by the working group. "A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, Thomas Schmidt, 2015-07-04, This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. "P2P Overlay Diagnostics", Haibin Song, Jiang Xingfeng, Roni Even, David Bryan, Yi Sun, 2015-01-23, This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. "A Usage for Shared Resources in RELOAD (ShaRe)", Alexander Knauf, Thomas Schmidt, Gabriel Hege, Matthias Waehlisch, 2015-06-17, This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. Pseudowire And LDP-enabled Services (pals) ------------------------------------------ "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)", Yuanlong Jiang, Lucy Yong, Manuel Paul, 2015-03-31, A generic Virtual Private LAN Service (VPLS) solution is specified for Ethernet-Tree (E-Tree) services which uses VLANs to indicate root or leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by PWs which carry the VLAN indicating the E-Tree attribute, the MAC address based Ethernet forwarding engine and the PW work in the same way as before. A signaling mechanism for E-Tree capability and VLAN mapping negotiation is further described. "STP Application of ICCP", Mingui Zhang, Huafeng Wen, Jie Hu, 2015-03-09, Inter-Chassis Communication Protocol (ICCP) supports the inter- chassis redundancy mechanism which achieves high network availability. In this document, the PEs in a Redundant Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data of the STP network. The operation logic of the application and the usage of these ICCP TLVs are specified. "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", Frederic JOUNAY, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, Mach Chen, Lizhong Jin, 2015-06-05, This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. "Using A Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator", Tom Nadeau, Luca Martini, Stewart Bryant, 2015-05-26, This document specifies a new Virtual Circuit Connectivity Verification (VCCV) (RFC5085) control channel type for use with pseudowires (PW) carried over an MPLS network. This new channel type uses the Generic Associated Channel Label (GAL) (RFC5586) to distinguish VCCV packets from packets carrying user data. "Pseudowire Redundancy on S-PE", Jie Dong, Haibo Wang, 2015-05-04, This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Operations of the S-PEs which provide PW redundancy are specified in this document. Signaling of the preferential forwarding status as defined in [RFC 6870] is reused. This document does not require any change to the T-PEs of MS-PW. "LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire", Fei Zhang, Wu Bo, Elisa Bellagamba, Mach Chen, 2015-07-06, This document defines extensions to LDP to configure proactive OAM functions for both SS-PW and MS-PW when the PW control plane is used. "LDP Extensions for Pseudowire Binding to LSP Tunnels", Mach Chen, Wei Cao, Attila Takacs, 2015-06-23, Many transport services require that user traffic, in the forms of Pseudowires (PW), to be delivered on a single co-routed bidirectional LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document defines an optional extension to LDP that enables the binding between PWs and the underlying LSPs. "S-PE Outage Protection for Static Multi-Segment Pseudowires", Andrew Malis, Loa Andersson, Huub van Helvoort, Jongyoon Shin, Lei Wang, Alessandro D'Alessandro, 2015-06-01, In MPLS and MPLS-TP environments, statically provisioned Single- Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the switching PEs (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. "MAC Address Withdrawal over Static Pseudowire", Siva Sivabalan, Sami Boutros, Himanshu Shah, Sam Aldrin, Mannan Venkatesan, 2015-07-05, This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. "Pseudowire Setup and Maintenance using the Label Distribution Protocol", Luca Martini, Giles Heron, 2015-06-19, Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. This document has been written to address errata in a previous version of this standard. "Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection", Weiqiang Cheng, Lei Wang, Han Li, Kai Liu, Shahram Davari, Jie Dong, Alessandro D'Alessandro, 2015-04-16, In some scenarios, the MPLS Trasport Profile (MPLS-TP) Pseudowires (PWs) are provisioned through either static configuration or management plane, where a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of Attachment Circuit (AC), the failure of Provider Edge (PE) and also the failure in the Packet Switched Network (PSN). The framework and scenarios for dual-homing pseudowire (PW) local protection are described in [draft-ietf-pals- mpls-tp-dual-homing-protection]. This document proposes a dual- homing coordination mechanism for MPLS-TP PWs, which is used for state exchange and coordination between the dual-homing PEs for dual- homing PW local protection. "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires", Weiqiang Cheng, Lei Wang, Han Li, Kai Liu, Shahram Davari, Jie Dong, Alessandro D'Alessandro, 2015-04-16, This document describes a framework and several scenarios for pseudowire (PW) dual-homing local protection. A Dual-Node Interconncetion (DNI) PW is provisioned between the dual-homing Provider Edge (PE) nodes for carrying traffic when failure accurs in the Attachment Circuit (AC) or PW side. In order for the dual-homing PE nodes to determine the forwarding state of AC, PW and the DNI PW, necessary state exchange and coordination between the dual-homing PEs are needed. The PW dual-homing local protection mechanism is complementary to the existing PW protection mechanisms. "Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)", Olivier Dornon, Jayant Kotalwar, Venu Hemige, Ray Qiu, 2015-04-21, This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via Protocol Independent Multicast (PIM) snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, Provider Edges (PEs) do not flood PIM Join/Prune messages but only generate their own and send out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Equipment (CE) devices and useful to reduce PIM control traffic in a VPLS domain. The document also describes PIM relay, which can be viewed as light- weight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports but not flooded to avoid triggering PIM Join suppression on CE devices. "Multi-chassis PON Protection in MPLS", Yuanlong Jiang, Yong Luo, Edwin Mallette, Yimin Shen, Guangtao Zhou, 2015-07-06, MPLS is being deployed deeper into operator networks, often to or past the access network node. Separately network access nodes such as PON OLTs have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multi-homing support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the multi-chassis PON protection architecture in MPLS and also proposes the ICCP extension to support it. "PW Endpoint Fast Failure Protection", Yimin Shen, Rahul Aggarwal, Wim Henderickx, Yuanlong Jiang, 2015-05-06, This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Designed on the basis of multi-homed CE, redundant PWs, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore PW traffic in the order of tens of milliseconds, by transmitting the traffic to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. Audio/Video Transport Payloads (payload) ---------------------------------------- "How to Write an RTP Payload Format", Magnus Westerlund, 2015-05-04, This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. "RTP Payload Format for VP8 Video", Patrik Westin, Henrik Lundin, Michael Glover, Justin Uberti, Frank Galligan, 2015-06-05, This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. "RTP Payload Format for G.711.0", Michael Ramalho, Paul Jones, Noboru Harada, Muthu Perumal, Miao Lei, 2015-05-11, This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. "RTP Payload Format for High Efficiency Video Coding", Ye-Kui Wang, Yago Sanchez, Thomas Schierl, Stephan Wenger, Miska Hannuksela, 2015-06-03, This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. "RTP Payload Format for Non-Interleaved and Interleaved Parity Forward Error Correction (FEC)", Varun Singh, Ali Begen, Mo Zanaty, 2015-02-14, This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols. These repair symbols are sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications, but endpoints that do not implement the scheme can still work by simply ignoring the FEC packets. "RTP Payload for SMPTE ST 291 Ancillary Data", Thomas Edwards, 2015-06-03, This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). "RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus Flodman, Jonathan Lennox, Danny Hong, 2015-07-06, This memo describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. Path Computation Element (pce) ------------------------------ "PCEP Extensions for Stateful PCE", Edward Crabbe, Ina Minei, Jan Medved, Robert Varga, 2015-04-20, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. "Standard Representation of Domain-Sequence", Dhruv Dhody, Udayasree Palle, Ramon Casellas, 2015-04-30, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a standard representation and encoding of a Domain-Sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains . This document also defines new subobjects to be used to encode domain identifiers. "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv Dhody, Qin Wu, Vishwas Manral, Zafar Ali, Kenji Kumaki, 2015-02-27, In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency Variation (jitter) and Packet Loss are becoming key requirements for path computation along with other constraints and metrics. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The Link Bandwidth Utilization (the total bandwidth of a link in current use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric extensions describes mechanisms with which network performance information is distributed via OSPF and IS-IS respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document describes the extension to PCEP to carry Latency, Latency Variation, Packet Loss, and Link Bandwidth Utilization as constraints for end to end path computation. "PCEP Extension for WSON Routing and Wavelength Assignment", Young Lee, Ramon Casellas, 2015-06-01, This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. "Applicability of a Stateful Path Computation Element (PCE)", Xian Zhang, Ina Minei, 2015-04-28, A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)", Fatai Zhang, Quintin Zhao, Oscar Gonzalez de Dios, Ramon Casellas, Daniel King, 2015-01-27, The Hierarchical Path Computation Element (H-PCE) architecture, provides a mechanism to allow the optimum sequence of domains to be selected,and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing Hierarchical PCE procedures which are described in the aforementioned document. These extensions are experimental and published for examination, discussion, implementation, and evaluation. "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Edward Crabbe, Ina Minei, Siva Sivabalan, Robert Varga, 2015-04-20, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions for stateful PCE provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. "Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks", Xian Zhang, Young Lee, Fatai Zhang, Ramon Casellas, Oscar Gonzalez de Dios, Zafar Ali, 2015-07-05, The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. "Secure Transport for PCEP", Diego Lopez, Oscar Gonzalez de Dios, Wenson Wu, Dhruv Dhody, 2015-05-05, The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describe the usage of Transport Layer Security (TLS) to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect the flexibility and extensibility of PCEP. "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", Edward Crabbe, Ina Minei, Jan Medved, Robert Varga, Xian Zhang, Dhruv Dhody, 2015-01-13, A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a reliable state synchronization mechanism between the PCE and the network, PCE and path computation clients (PCCs), and between cooperating PCEs. The basic mechanism for state synchronization is part of the stateful PCE specification. This draft presents motivations for optimizations to the base state synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. "Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup", Zafar Ali, Siva Sivabalan, Clarence Filsfils, Robert Varga, Victor Lopez, Oscar Gonzalez de Dios, Xian Zhang, 2015-07-06, Draft [I-D. draft-ietf-pce-pce-initiated-lsp] specifies procedures that can be used for creation and deletion of PCE-initiated LSPs in the active stateful PCE model. However, this specification focuses on MPLS networks, and does not cover remote instantiation of paths in GMPLS-controlled networks. This document complements [I-D. draft-ietf-pce-pce-initiated-lsp] by addressing the requirements for remote-initiated GMPLS LSPs. "Conveying path setup type in PCEP messages", Siva Sivabalan, Jan Medved, Ina Minei, Edward Crabbe, Robert Varga, Jeff Tantsura, Jonathan Hardwick, 2015-06-23, A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. "PCEP Extensions for Segment Routing", Siva Sivabalan, Jan Medved, Clarence Filsfils, Edward Crabbe, Victor Lopez, Jeff Tantsura, Wim Henderickx, Jonathan Hardwick, 2015-05-31, Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. "Update to Include Route Object (IRO) specification in Path Computation Element communication Protocol (PCEP)", Dhruv Dhody, 2015-05-20, During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs, it was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). An informal survey was conducted to determine the state of current and planned implementation with respect to IRO ordering and handling of Loose bit (L bit). This document updates the IRO specification based on the survey conclusion and recommendation. Port Control Protocol (pcp) --------------------------- "Port Control Protocol (PCP) Proxy Function", Simon Perreault, Mohamed Boucadair, Reinaldo Penno, Dan Wing, Stuart Cheshire, 2015-05-26, This document specifies a new PCP functional element denoted as a PCP Proxy. The PCP Proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that can not be configured with the address of a PCP server located more than one hop away. "Port Control Protocol (PCP) Authentication Mechanism", Margaret Wasserman, Sam Hartman, Dacheng Zhang, Tirumaleswar Reddy, 2015-07-02, An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communication with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. This document updates RFC6887. "Port Control Protocol (PCP) Extension for Port Set Allocation", Qiong, Mohamed Boucadair, Senthil Sivakumar, Cathy Zhou, Tina Tsou, Simon Perreault, 2015-05-27, This document defines an extension to the Port Control Protocol (PCP) allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. "Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)", Tirumaleswar Reddy, Prashanth Patil, Markus Isomaki, Dan Wing, 2015-05-18, This document describes how Port Control Protocol is useful in reducing NAT and firewall keepalive messages for a variety of applications. "Port Control Protocol (PCP) Anycast Addresses", Sebastian Kiesel, Reinaldo Penno, Stuart Cheshire, 2015-05-19, The Port Control Protocol (PCP) Anycast Addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP Anycast Addresses. "PCP Third Party ID Option", Andreas Ripke, Rolf Winter, Thomas Dietz, Juergen Quittek, Rafael Silva, 2015-02-09, This document describes a new Port Control Protocol (PCP) option called THIRD_PARTY_ID. It is designed to be used in combination with the THIRD_PARTY option specified in RFC 6887 but can also be used without it. The THIRD_PARTY_ID serves to identify a Third Party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device. Protocols for IP Multicast (pim) -------------------------------- "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, Rishabh Parekh, Jeffrey Zhang, Lianshu Zheng, 2015-05-17, This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP),PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A) and moves the PIM specification to Internet Standard. "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Hitoshi Asaeda, 2015-03-09, This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers and IGMP/MLD proxy devices supporting IGMPv3/MLDv2. The explicit membership tracking function contributes to saving network resources and shortening leave latency. "Explicit RPF Vector", Javed Asghar, IJsbrand Wijnands, Sowmya Krishnaswamy, Apoorva Karan, Vishal Arya, 2015-05-08, The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the Source or RP associated with the multicast tree. This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, bypassing the unicast route lookup. "Hierarchical Join/Prune Attributes", Stig Venaas, Jesus Arango, Isidor Kouvelas, 2015-07-02, This document defines a hierachical method of encoding Join attributes, providing a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message. "PIM flooding mechanism and source discovery", IJsbrand Wijnands, Stig Venaas, Michael Brig, Anders Jonasson, 2015-07-01, PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to forward multicast packets to Last Hop Routers (LHR). After the first packet is received by the LHR, the source of the multicast stream is learned and the Shortest Path Tree (SPT) can be joined. This draft proposes a solution to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM flooding mechanism. This mechanism is defined in this document, and is modeled after the PIM Bootstrap Router protocol. By removing the need for RPs and shared trees, the PIM-SM procedures are simplified, improving router operations, management and making the protocol more robust. "PIM Join Attributes for LISP Environments", Jesus Arango, Stig Venaas, Isidor Kouvelas, 2015-07-06, This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different LISP sites. These attributes allow the receiver site to select between unicast and multicast transport and to convey the receiver RLOC address to the control plane of the root xTR. "Requiremnets for the extension of the MLD proxy functionality to support multiple upstream interfaces", Luis Contreras, Carlos Bernardos, 2015-07-08, The purpose of this document is to define the requirements for a MLD (for IPv6) or IGMP (for IPv4) proxy with multiple interfaces covering a variety of applicability scenarios. Peer to Peer Streaming Protocol (ppsp) -------------------------------------- "PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)", Rui Cruz, Mario Nunes, Gu Yingjie, Jinwei Xia, Rachel Huang, Joao Taveira, Deng Lingli, 2015-03-26, This document specifies the base Peer-to-Peer Streaming Protocol- Tracker Protocol (PPSP-TP/1.0), an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality, and describes message flows, message processing instructions, message formats, formal syntax and semantics. The PPSP Tracker Protocol enables cooperating peers to form content streaming overlay networks to support near real-time Structured Media content delivery (audio, video, associated timed text and metadata), such as adaptive multi-rate, layered (scalable) and multi-view (3D) videos, in live, time-shifted and on-demand modes. Preparation and Comparison of Internationalized Strings (precis) ---------------------------------------------------------------- "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", Peter Saint-Andre, 2015-06-26, This document describes methods for handling Unicode strings representing nicknames. "Mapping characters for PRECIS classes", Yoshiro Yoneya, T. Nemoto, 2015-07-06, The framework for preparation, enforcement, and comparison of internationalized strings ("PRECIS") defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it necessary to define methods for case mapping. In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters. "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", Peter Saint-Andre, Alexey Melnikov, 2015-05-28, This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013. RADIUS EXTensions (radext) -------------------------- "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Stefan Winter, Mike McCauley, 2015-04-29, This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. "Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)", Alan DeKok, 2015-04-01, RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. "Larger Packets for RADIUS over TCP", Sam Hartman, 2015-03-06, The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6113) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. "RADIUS Extensions for IP Port Configuration and Reporting", Dean Cheng, Jouni Korhonen, Mohamed Boucadair, Senthil Sivakumar, 2015-04-23, This document defines three new RADIUS attributes. For devices that implementing IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc. Real-time Applications and Infrastructure Area (rai) ---------------------------------------------------- "Considerations for Information Services and Operator Services Using SIP", John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell, 2011-08-15, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. "A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)", Jaime Jimenez, Jose Lopez-Vega, Jouni Maenpaa, Gonzalo Camarillo, 2015-06-09, This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------- "NADA: A Unified Congestion Control Scheme for Real-Time Media", Xiaoqing Zhu, Rong Pan, Michael Ramalho, Sergio de la Cruz, Charles Ganzhorn, Paul Jones, Stefano D'Aronco, 2015-03-26, Network-Assisted Dynamic Adaptation (NADA) is a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In NADA, the sender regulates its sending rate based on either implicit or explicit congestion signaling in a consistent manner. As one example of explicit signaling, NADA can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of explicit signaling by reacting to queuing delay and packet loss. This document describes the overall system architecture for NADA, as well as recommended behavior at the sender and the receiver. "Congestion Control Requirements for Interactive Real-Time Media", Randell Jesup, Zaheduzzaman Sarker, 2014-12-12, Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for real-time media congestion avoidance technique. "Evaluating Congestion Control for Interactive Real-time Media", Varun Singh, Joerg Ott, 2015-03-09, The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. "Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson, Zaheduzzaman Sarker, 2015-03-02, This memo describes a rate adaptation algorithm for conversational video services. The solution conforms to the packet conservation principle and uses a hybrid loss and delay based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LTE (Long Term Evolution) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. "Test Cases for Evaluating RMCAT Proposals", Zaheduzzaman Sarker, Varun Singh, Xiaoqing Zhu, Michael Ramalho, 2015-03-09, The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications, these applications are typically required to implement congestion control. The RMCAT working group is currently working on candidate algorithms for such interactive real- time multimedia applications. This document describes the test cases to be used in the performance evaluation of those candidate algorithms. "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.", David Hayes, Simone Ferlin, Michael Welzl, 2015-03-03, This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated by a data receiver based on continuous measurements and regularly fed to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. "NADA: A Unified Congestion Control Scheme for Real-Time Media", Xiaoqing Zhu, Rong Pan, Michael Ramalho, Sergio de la Cruz, Charles Ganzhorn, Paul Jones, Stefano D'Aronco, 2015-04-29, Network-Assisted Dynamic Adaptation (NADA) is a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In NADA, the sender regulates its sending rate based on either implicit or explicit congestion signaling in a consistent manner. As one example of explicit signaling, NADA can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of explicit signaling by reacting to queuing delay and packet loss. This document describes the overall system architecture for NADA, as well as recommended behavior at the sender and the receiver. "Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson, Zaheduzzaman Sarker, 2015-07-06, This memo describes a rate adaptation algorithm for conversational video services. The solution conforms to the packet conservation principle and uses a hybrid loss and delay based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LTE (Long Term Evolution) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.", David Hayes, Simone Ferlin, Michael Welzl, 2015-07-01, This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated by a data receiver based on continuous measurements and regularly fed to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", Zaheduzzaman Sarker, Ingemar Johansson, 2015-06-12, It is evident that to ensure seamless and robust user experience across all type of access networks multimedia communication suits should adapt to the changing network conditions. There is an ongoing effort in IETF RMCAT working group to standardize rate adaptive algorithm(s) to be used in the real-time interactive communication. In this document test cases are described to evaluate the performances of the proposed endpoint adaptation solutions in LTE networks and Wi-Fi networks. It is aimed that the proposed solutions should be evaluated using the test cases defined in this document to select most optimal solutions. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Multicast Protocol for Low power and Lossy Networks (MPL)", Jonathan Hui, Richard Kelsey, 2015-06-02, This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in a MPL Domain. MPL has two modes of operation. One mode uses the Trickle algorithm to manage control- and data-plane message transmissions, and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, a MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. "Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks", Daniel Popa, Matthew Gillmore, Laurent Toutain, Jonathan Hui, Kazuya Monden, Nancy Cam-Winget, 2015-01-30, This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. "ROLL Applicability Statement Template", Michael Richardson, 2015-05-11, This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template. "Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control", Anders Brandt, Emmanuel Baccelli, Robert Cragie, Peter Van der Stok, 2015-07-02, The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. "MPL Parameter Configuration Option for DHCPv6", Yusuke Doi, Matthew Gillmore, 2015-07-02, This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameters easily. "Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL)", Peter Van der Stok, Robert Cragie, 2015-02-06, The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ "Overview: Real Time Protocols for Browser-based Applications", Harald Alvestrand, 2015-06-16, This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Colin Perkins, Magnus Westerlund, Joerg Ott, 2015-06-12, The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. "Security Considerations for WebRTC", Eric Rescorla, 2015-02-26, The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. "WebRTC Security Architecture", Eric Rescorla, 2015-03-07, The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC. "Javascript Session Establishment Protocol", Justin Uberti, Cullen Jennings, Eric Rescorla, 2015-07-05, This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. "WebRTC Data Channels", Randell Jesup, Salvatore Loreto, Michael Tuexen, 2015-01-04, The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. "WebRTC Audio Codec and Processing Requirements", Jean-Marc Valin, Cary Bran, 2015-04-30, This document outlines the audio codec and processing requirements for WebRTC endpoints. "WebRTC Data Channel Establishment Protocol", Randell Jesup, Salvatore Loreto, Michael Tuexen, 2015-01-04, The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. "Transports for WebRTC", Harald Alvestrand, 2015-07-06, This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. "STUN Usage for Consent Freshness", Muthu Perumal, Dan Wing, Ram R, Tirumaleswar Reddy, Martin Thomson, 2015-06-22, To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. "WebRTC Video Processing and Codec Requirements", Adam Roach, 2015-06-12, This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. "IANA Registry for RTCWeb Constrainable Properties", Daniel Burnett, 2015-03-09, Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of constrainable properties for HTML media and other constrainable objects. This document defines this registry. "Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)", Martin Thomson, 2015-02-28, Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection. "Additional WebRTC audio codecs for interoperability.", Stephane Proust, Espen Berger, Bernhard Feiten, Bo Burman, Kalyani Bogineni, Miao Lei, Enrico Marocco, 2015-01-16, To ensure a baseline level of interoperability between WebRTC clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. "WebRTC Forward Error Correction Requirements", Justin Uberti, 2015-03-08, This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC applications. "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", Benjamin Schwartz, Justin Uberti, 2015-05-13, In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. "WebRTC Gateways", Harald Alvestrand, Uwe Rauschenbach, 2015-07-06, This document describes interoperability considerations for a class of WebRTC-compatible endpoints called "WebRTC gateways", which interconnect between WebRTC endpoints and devices that are not WebRTC endpoints. Routing Area (rtg) ------------------ "A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD)", Palanivelan Appanasamy, 2011-11-17, This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", Ali Sajassi, Samer Salam, Nabil Bitar, Aldrin Isaac, Wim Henderickx, 2015-05-14, This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Conventions "ForCES Inter-FE LFB", Damascane Joachimpillai, Jamal Hadi Salim, 2015-03-06, This document describes extending the ForCES LFB topology across FEs i.e inter-FE connectivity without needing any changes to the ForCES specification by defining the Inter-FE LFB. The Inter-FE LFB provides ability to pass data, metadata and exceptions across FEs. The document describes a generic way to transport the mentioned details but focuses on ethernet transport. "IETF ForCES Logical Function Block (LFB) Subsidiary Management", Bhumip Khasnabish, Evangelos Haleplidis, Jamal Hadi Salim, 2015-05-16, Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modelled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB, an LFB that specifies the configuration parameters of an FE. Routing Area Working Group (rtgwg) ---------------------------------- "IP MIB for IP Fast-Reroute", Alia Atlas, Kiran Koushik, John Flick, Stephane Litkowski, 2015-06-15, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects relevant for IP routes using IP Fast-Reroute [RFC5714] "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, Chris Bowers, Gabor Envedi, Andras Csaszar, Jeff Tantsura, Russ White, 2015-07-03, With increasing deployment of Loop-Free Alternates (LFA) [RFC5286], it is clear that a complete solution for IP and LDP Fast-Reroute is required. This specification provides that solution. IP/LDP Fast- Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. MRT removes all need to engineer for coverage. MRT is also extremely computationally efficient. For any router in the network, the MRT computation is less than the LFA computation for a node with three or more neighbors. "Multicast only Fast Re-Route", Apoorva Karan, Clarence Filsfils, IJsbrand Wijnands, Bruno Decraene, 2015-05-18, As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast only Fast Re- Route (MoFRR) works by making simple enhancements to multicast routing protocols such as PIM and mLDP. "Operational management of Loop Free Alternates", Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, Martin Horneffer, P. Sarkar, 2015-06-25, Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute", Gabor Envedi, Andras Csaszar, Alia Atlas, Chris Bowers, Abishek Gopalan, 2015-07-02, A complete solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr- architecture]. This document defines the associated MRT Lowpoint algorithm that is used in the default MRT profile to compute both the necessary Maximally Redundant Trees with their associated next-hops and the alternates to select for MRT-FRR. "Remote-LFA Node Protection and Manageability", P. Sarkar, Hannes Gredler, Shraddha Hegde, Chris Bowers, Stephane Litkowski, Harish Raghuveer, 2015-06-15, The loop-free alternates computed following the current Remote-LFA [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link- protection. The resulting Remote-LFA nexthops (also called PQ- nodes), may not gaurantee node-protection for all destinations being protected by it. This document describes procedures for determining if a given PQ-node provides node-protection for a specific destination or not. The document also shows how the same procedure can be utilised for collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate path is precursory to apply operator defined policy for eliminating paths not fitting constraints. "Use of BGP for routing in large-scale data centers", Petr Lapukhov, Ariff Premji, Jon Mitchell, 2015-06-15, Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry. "SPF Back-off algorithm for link state IGPs", Bruno Decraene, Stephane Litkowski, Hannes Gredler, Acee Lindem, P. Francois, 2015-06-19, This document defines a standard algorithm to back-off link-state IGP SPF computations. Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple proximate IGP events. "Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops", Stephane Litkowski, Bruno Decraene, Martin Horneffer, 2015-06-23, A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. "Encapsulation Considerations", Erik Nordmark, Albert Tian, Jesse Gross, Jon Hudson, Lawrence Kreeger, Pankaj Garg, Patricia Thaler, Tom Herbert, 2015-07-06, The IETF Routing Area director has chartered a design team to look at common issues for the different data plane encapsulations being discussed in the NVO3 and SFC working groups and also in the BIER BoF, and also to look at the relationship between such encapsulations in the case that they might be used at the same time. The purpose of this design team is to discover, discuss and document considerations across the different encapsulations in the different WGs/BoFs so that we can reduce the number of wheels that need to be reinvented in the future. Security Automation and Continuous Monitoring (sacm) ---------------------------------------------------- "Endpoint Security Posture Assessment - Enterprise Use Cases", David Waltermire, David Harrington, 2015-07-01, This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture. "Secure Automation and Continuous Monitoring (SACM) Terminology", Henk Birkholz, 2015-07-06, This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). "Secure Automation and Continuous Monitoring (SACM) Requirements", Nancy Cam-Winget, Lisa Lorenzin, 2015-07-08, This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring (SACM) architecture, data model and protocols. The requirements and scope are based on the agreed upon use cases. "Secure Automation and Continuous Monitoring (SACM) Architecture", Nancy Cam-Winget, Lisa Lorenzin, Ira McDonald, loxx@cisco.com, 2015-03-09, This document defines a reference architecture for standardization of interfaces, protocols, and information models related to security automation and continuous monitoring. It describes the basic architecture, components, and their interfaces defined to enable the collection, acquisition, and verification of Posture and Posture Assessments. "SACM Information Model", David Waltermire, Kim Watson, Clifford Kahn, Lisa Lorenzin, 2015-07-06, This document proposes an information model for SACM. Source Address Validation Improvements (savi) --------------------------------------------- "SAVI for Mixed Address Assignment Methods Scenario", Jun Bi, Guang Yao, Joel Halpern, Eric Levy-Abegnoli, 2015-05-13, In case that multiple IP address assignment methods are allowed in a network, the corresponding SAVI methods should be enabled to prevent spoofing in the network. This document reviews how multiple SAVI methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. System for Cross-domain Identity Management (scim) -------------------------------------------------- "System for Cross-Domain Identity Management: Protocol", Phil Hunt, Kelly Grizzle, Morteza Ansari, Erik Wahlstroem, Chuck Mortimore, 2015-05-15, The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized service. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. "System for Cross-Domain Identity Management: Core Schema", Phil Hunt, Kelly Grizzle, Erik Wahlstroem, Chuck Mortimore, 2015-06-08, The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. "SCIM Definitions, Overview, Concepts and Requirements", Kepeng Li, Phil Hunt, Bhumip Khasnabish, Anthony Nadalin, Zachary Zeltsan, 2015-05-07, This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models and flows, and includes user scenarios, use cases, and requirements. Security Area (sec) ------------------- "X.509v3 TLS Feature Extension", Phillip Hallam-Baker, 2015-07-06, The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial of service attack that might otherwise be possible. "Domain-based signing and encryption using S/MIME", William Ottaway, Alexey Melnikov, 2014-03-05, The S/MIME protocols Message Specification (RFC 5751), Cryptographic Message Syntax (RFC 5652), S/MIME Certificate Handling (RFC 5750) and Enhanced Security Services for S/MIME (RFC 2634) specify a consistent way to securely send and receive MIME messages providing end to end integrity, authentication, non-repudiation and confidentiality. This document identifies a number of interoperability, technical, procedural and policy related issues that may result in end-to-end security services not being achievable. To resolve such issues, this document profiles domain-based signing and encryption using S/MIME, such as specifying how S/MIME signing and encryption can be applied between a Message Submission Agent (MSA) and a Message Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA). This document is also registering 2 URI scheme: "smtp" and "submit" which are used for designating SMTP/SMTP Submission servers (respectively), as well as SMTP/Submission client accounts. "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", Russ Housley, 2015-07-07, Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. Service Function Chaining (sfc) ------------------------------- "Service Function Chaining Use Cases In Data Centers", Surendra, Mudassir Tufail, Sumandra Majee, Claudiu Captari, Shunsuke Homma, 2015-01-19, Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. "Service Function Chaining Use Cases in Mobile Networks", Walter Haeffner, Jeffrey Napper, Martin Stiemerling, Diego Lopez, Jim Uttaro, 2015-01-13, This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement [ietf-sfc-problem-statement] and architecture framework [ietf-sfc-arch] of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains (SFC) ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery or take care of security and privacy. SFCs may also include Value Added Services (VAS). Commonly, SFCs are typical middlebox services. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. "SFC Long-lived Flow Use Cases", Ram (Ramki) Krishnan, Anoop Ghanwani, Joel Halpern, Sriganesh Kini, Diego Lopez, 2015-02-06, Long-lived flows such as file transfers, video streams are common in today's networks. In the context of service function chaining, this draft suggests use cases for dynamic bypass of certain service functions for such flows. The benefit of this approach would be to avoid expensive Layer 7 service function processing for such flows based on dynamic decisions and thus improve overall performance. "Service Function Chaining (SFC) Architecture", Joel Halpern, Carlos Pignataro, 2015-06-07, This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. "Network Service Header", Paul Quinn, Uri Elzur, 2015-03-24, This draft describes a Network Service Header (NSH) inserted onto encapsulated packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. Secure Inter-Domain Routing (sidr) ---------------------------------- "Securing RPSL Objects with RPKI Signatures", kistel, Brian Haberman, 2015-05-11, This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", Samuel Weiler, Anuja Sonalker, Rob Austein, 2015-02-25, This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so. "BGPsec Protocol Specification", Matt Lepinski, 2015-07-06, This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via a new optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. "An Overview of BGPsec", Matt Lepinski, spt, 2015-06-14, This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves security for BGP routing. "BGPsec Operational Considerations", Randy Bush, 2015-07-02, Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. "BGP Algorithms, Key Formats, & Signature Formats", spt, 2015-01-21, This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", Mark Reynolds, spt, Stephen Kent, 2015-01-21, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS) or ASes. The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS(es). This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). "Router Keying for BGPsec", spt, Keyur Patel, Randy Bush, 2015-01-21, BGPsec-speaking routers are provisioned with private keys to sign BGP messages; the corresponding public keys are published in the global RPKI (Resource Public Key Infrastructure) thereby enabling verification of BGPsec messages. This document describes two ways of provisioning the public-private key-pairs: router-driven and operator-driven. "BGPsec Router Certificate Rollover", Roque Gagliano, Keyur Patel, Brian Weis, 2015-07-06, BGPsec will need to address the impact from regular and emergency rollover processes for the BGPsec End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec EE certificates must be carefully managed in order to synchronize distribution of router public keys and the usage of those pubic keys by BGPsec routers. This document provides general recommendations for that process, as well as describing reasons why the rollover of BGPsec EE certificates might be necessary. "BGPSec Considerations for AS Migration", Wesley George, Sandra Murphy, 2015-02-04, This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. "RPKI Local Trust Anchor Use Cases", Randy Bush, 2015-06-24, There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. "The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure", Geoff Huston, George Michaelson, 2015-05-15, This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties that verify these digital signatures. "The Resource Public Key Infrastructure (RPKI) to Router Protocol", Randy Bush, Rob Austein, 2015-06-15, In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver validated prefix origin data and router keys to routers. "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", Geoff Huston, Samuel Weiler, George Michaelson, Stephen Kent, 2015-05-14, This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by adding support for multiple URIs in a TAL. "RPKI Validation Reconsidered", Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton, Alain Aina, 2015-01-24, This document reviews the certificate validation procedure specified in RFC6487 and highlights aspects of operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement. "RPKI Repository Delta Protocol", Tim Bruijnzeels, Oleg Muravskiy, Bryan Weber, Rob Austein, David Mandelberg, 2015-02-16, In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia, Geir Sandbakken, 2013-01-13, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. Session Initiation Protocol Core (sipcore) ------------------------------------------ "Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network", oej, Gonzalo Salgueiro, Vijay Gurbani, 2015-02-02, RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document supplements the DNS procedures described in RFC 3263 for dual-stack SIP implementations and ensures that they properly align to the optimizations detailed by Happy Eyeballs. "Explicit Subscriptions for the REFER Method", Robert Sparks, 2015-06-25, The Session Initiation Protocol (SIP) REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines extensions to REFER to remove the implicit subscription and, if desired, replace it with an explicit one. "Clarifications for the use of REFER with RFC6665", Robert Sparks, Adam Roach, 2015-04-22, The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. "A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework", Adam Roach, 2015-02-27, Experience since the publication of the most recent SIP Events framework has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior. This document updates RFC 6665. SIP Recording (siprec) ---------------------- "Session Initiation Protocol (SIP) Recording Metadata", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 2015-02-12, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. "Session Recording Protocol", Leon Portman, Henry Lum, Charles Eckel, Alan Johnston, Andrew Hutton, 2015-07-02, This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. "Session Initiation Protocol (SIP) Recording Call Flows", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 2015-02-28, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows that has snapshot of metadata sent from SRC to SRS. This is purely an informational document that is written to support the model defined in the metadata draft. Softwires (softwire) -------------------- "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", Jacni Qin, Mohamed Boucadair, Christian Jacquenet, Yiu Lee, Qian Wang, 2015-03-09, This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to DS-Lite serviced customers. "Softwire Mesh Multicast", Mingwei Xu, Yong Cui, Jianping Wu, Shu Yang, Chris Metz, Greg Shepherd, 2015-01-22, The Internet needs to support IPv4 and IPv6 packets. Both address families and their related protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwire Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwire mesh. "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Mohamed Boucadair, Jacni Qin, Tina Tsou, Xiaohong Deng, 2015-03-09, This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses. "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", Remi Despres, Sheng Jiang, Reinaldo Penno, Yiu Lee, Gang Chen, Maoke Chen, 2014-12-08, For service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers, this document specifies a stateless solution. Its distinctive property is that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal, and that IPv4 fragmentation rules are fully preserved end- to-end. Each customer can be assigned one public IPv4 address, or several, or a shared address with a restricted port set. "Mapping of Address and Port with Encapsulation (MAP)", Ole Troan, Wojciech Dec, Xing Li, Congxiao Bao, Satoru Matsushima, Tetsuya Murakami, Tom Taylor, 2015-03-09, This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. "Softwire Mesh Management Information Base (MIB)", Yong Cui, Jiang Dong, Peng Wu, Mingwei Xu, Antti Yla-Jaaski, 2015-03-05, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh. "DS-Lite Management Information Base (MIB)", Yu Fu, Sheng Jiang, Jiang Dong, Yuchi Chen, 2015-03-25, This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for Dual-Stack Lite (DS-Lite). "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", Tomek Mrugalski, Ole Troan, Ian Farrer, Simon Perreault, Wojciech Dec, Congxiao Bao, Leaf Yeh, Xiaohong Deng, 2015-03-09, This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network. "Mapping of Address and Port using Translation (MAP-T)", Xing Li, Congxiao Bao, Wojciech Dec, Ole Troan, Satoru Matsushima, Tetsuya Murakami, 2014-12-02, This document specifies the "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) based solution architecture for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. "Mapping of Address and Port (MAP) - Deployment Considerations", Qiong, Maoke Chen, Gang Chen, Tina Tsou, Simon Perreault, 2015-06-09, This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. "Lightweight 4over6: An Extension to the DS-Lite Architecture", Yong Cui, Qiong, Mohamed Boucadair, Tina Tsou, Yiu Lee, Ian Farrer, 2014-11-13, Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. "Definitions of Managed Objects for MAP-E", Yu Fu, Sheng Jiang, Bing Liu, Jiang Dong, Yuchi Chen, 2015-06-17, This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. "RADIUS Attribute for MAP", Sheng Jiang, Yu Fu, Bing Liu, Peter Deacon, 2015-06-22, Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. Source Packet Routing in Networking (spring) -------------------------------------------- "SPRING Problem Statement and Requirements", Stefano Previdi, Clarence Filsfils, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Rob Shakir, 2015-04-27, The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed' and therefore it is not limited to the originator of the packet (i.e.: the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. "Use-cases for Resiliency in SPRING", P. Francois, Clarence Filsfils, Bruno Decraene, Rob Shakir, 2015-03-23, This document describes the use cases for resiliency in SPRING networks. "IPv6 SPRING Use Cases", John Brzozowski, John Leddy, Ida Leung, Stefano Previdi, W. Townsley, Christian Martin, Clarence Filsfils, Roberta Maglione, 2015-03-06, Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. "Segment Routing Architecture", Clarence Filsfils, Stefano Previdi, Bruno Decraene, Stephane Litkowski, Rob Shakir, 2015-05-28, Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing extension header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer in the routing extension header. Upon completion of a segment, the pointer is incremented. "Segment Routing with MPLS data plane", Clarence Filsfils, Stefano Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Rob Shakir, Jeff Tantsura, Edward Crabbe, 2015-05-29, Segment Routing (SR) leverages the source routing paradigm. 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 to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. "YANG Data Model for Segment Routing", Stephane Litkowski, Yingzhen Qu, P. Sarkar, Jeff Tantsura, 2015-06-23, This document defines a YANG data model ([RFC6020]) for segment routing ([I-D.ietf-spring-segment-routing]) configuration and operation. This YANG model is intended to be used on network elements to configure or operate segment routing. This document defines also generic containers that SHOULD be reused by IGP protocol modules to support segment routing. "OAM Requirements for Segment Routing Network", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Ruediger Geib, Greg Mirsky, Stephane Litkowski, 2015-06-30, This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. Secure Telephone Identity Revisited (stir) ------------------------------------------ "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, Eric Rescorla, 2015-07-06, The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining new SIP header fields for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. "Secure Telephone Identity Credentials: Certificates", Jon Peterson, spt, 2015-07-06, In order to prove ownership of telephone numbers on the Internet, some kind of public infrastructure needs to exist that binds cryptographic keys to authority over telephone numbers. This document describes a certificate-based credential system for telephone numbers, which could be used as a part of a broader architecture for managing telephone numbers as identities in protocols like SIP. SIP-TO-XMPP (stox) ------------------ "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat", Peter Saint-Andre, Saul Corretge, Salvatore Loreto, 2015-03-05, This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions", Peter Saint-Andre, Saul Corretge, Emil Ivov, 2015-07-05, This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of media signaling messages between systems that implement the Session Initiation Protocol (SIP) and systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, 2015-06-11, This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. Sip Traversal Required for Applications to Work (straw) ------------------------------------------------------- "Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)", Lorenzo Miniero, Sergio Murillo, Victor Pascual, 2015-04-21, SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. "DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro, Victor Pascual, Parthasarathi Ravindran, 2015-06-18, Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often function on the media plane, rather than just on the signaling path. This document describes the behavior B2BUAs should follow when acting on the media plane that use Secure Real-time Transport (SRTP) security context setup with Datagram Transport Layer Security (DTLS) protocol. Sunsetting IPv4 (sunset4) ------------------------- "Gap Analysis for IPv4 Sunset", Simon Perreault, Tina Tsou, Cathy Zhou, Peng Fan, 2015-04-22, Sunsetting IPv4 refers to the process of turning off IPv4 definitively. It can be seen as the final phase of the migration to IPv6. This memo enumerates difficulties arising when sunsetting IPv4, and identifies the gaps requiring additional work. "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Gang Chen, Weibo Li, Tina Tsou, Jing Huang, Tom Taylor, 2015-05-18, This document enumerates methods of port assignment in Carrier Grade NATs (CGNs), focused particularly on NAT64 environments. A theoretical framework of different NAT port allocation methods is described. The memo is intended to clarify and focus the port allocation discussion and propose an integrated view of the considerations for selection of the port allocation mechanism in a given deployment. Transport Services (taps) ------------------------- "Services provided by IETF transport protocols and congestion control mechanisms", Gorry Fairhurst, Brian Trammell, Mirja Kuehlewind, 2015-07-06, This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Problem Statement and Requirements for a More Accurate ECN Feedback", Mirja Kuehlewind, Richard Scheffenegger, Bob Briscoe, 2015-03-09, Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. "Updating TCP to support Rate-Limited Traffic", Gorry Fairhurst, Arjuna Sathiaseelan, Raffaello Secchi, 2015-06-25, This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. "TCP and SCTP RTO Restart", Per Hurtig, Anna Brunstrom, Andreas Petlund, Michael Welzl, 2015-06-18, This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. "TCP Extended Data Offset Option", Joseph Touch, Wesley Eddy, 2015-04-15, TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. "CUBIC for Fast Long-Distance Networks", Injong Rhee, Lisong Xu, Sangtae Ha, Alexander Zimmermann, Lars Eggert, Richard Scheffenegger, 2015-06-18, CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. "Transmission Control Protocol Specification", Wesley Eddy, 2015-06-22, This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------- "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Adrian Farrel, John Drake, Nabil Bitar, George Swallow, Daniele Ceccarelli, Xian Zhang, 2015-03-08, In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement and architecture for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. "RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing", Xian Zhang, zhenghaomian@huawei.com, Rakesh Gandhi, Zafar Ali, Gabriele Galimberti, Pawel Brzozowski, 2015-01-30, In transport networks, there are requirements where Generalized Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs. This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document clarifies the RSVP-TE signaling procedure to support resource sharing-based setup and teardown of LSPs as well as LSP reversion. No new extensions are defined by this document, and it is strictly informative in nature. "RSVP Extensions For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)", Tarek Saad, Rakesh Gandhi, Zafar Ali, Robert Venator, Yuji Kamite, 2015-05-25, For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re-evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub-group of S2L sub-LSP(s) basis only. This document defines Resource Reservation Protocol (RSVP) signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This document defines markers to indicate beginning and end of an S2L sub-LSP descriptor list when the RSVP message needs to be fragmented due to large number of S2L sub-LSPs in the message when performing sub-group based re-optimization. "Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy, Ramon Casellas, 2015-04-30, The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS)). Note that the use of AS as an abstract node representing domain is already defined in existing RSVP-TE specefications, albeit with a 2-Byte AS number. "Network Assigned Upstream-Label", Vishnu Pavan Beeram, Igor Bryskin, 2015-03-05, This document discusses a GMPLS RSVP-TE protocol mechanism that enables the network to assign an upstream-label for a given LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream-label on its own and needs to rely on the network to pick an appropriate label. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route", Zafar Ali, George Swallow, Fatai Zhang, Dieter Beller, 2015-07-06, RFC 4874 specifies methods by which path exclusions can be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies procedures for additional route exclusion subobject based on Paths currently existing or expected to exist within the network. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Kenji Kumaki, Ruediger Kunze, 2015-07-06, There are many scenarios in which Traffic Engineering (TE) metrics such as cost, Delay and Delay variation associated with the TE link formed by Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to support automatic collection of cost, Delay and Delay variation information for the TE link formed by a LSP. "RSVP-TE Extensions for Collecting SRLG Information", Fatai Zhang, Oscar Gonzalez de Dios, Matt Hartley, Zafar Ali, Cyril Margaria, 2015-06-25, This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). "Requirements for Very Fast Setup of GMPLS LSPs", Andrew Malis, Brian Wilson, George Clapp, Vishnu Shukla, 2015-06-11, Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality of service differentiation, and different levels of resilience. The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS). "Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs", Mike Taillon, Tarek Saad, Rakesh Gandhi, Zafar Ali, Manav Bhatia, Lizhong Jin, 2015-01-26, This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. "Extensions to RSVP-TE for LSP Egress Local Protection", Huaimo Chen, Ning So, Autumn Liu, Tarek Saad, Fengman Xu, 2015-06-18, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. "Extensions to RSVP-TE for LSP Ingress Local Protection", Huaimo Chen, Raveendra Torvi, 2015-06-20, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. "Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions", Alia Atlas, John Drake, Spencer Giacalone, David Ward, Stefano Previdi, Clarence Filsfils, 2015-06-09, In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification uses network performance data, such as is advertised via the OSPF and ISIS TE metric extensions (defined outside the scope of this document) to perform such path selections. "YANG Data Model for TE Topologies", Xufeng Liu, Igor Bryskin, Vishnu Pavan Beeram, Tarek Saad, Himanshu Shah, Oscar Gonzalez de Dios, 2015-07-06, This document defines a YANG data model for representing, retrieving and manipulating TE Topologies. The model serves as a base model that other technology specific TE Topology models can augment. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Precision Time Protocol Version 2 (PTPv2) Management Information Base", Vinay Shankarkumar, Laurent Montini, Tim Frost, Greg Dowd, 2015-03-25, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Precision Time Protocol, specified in IEEE Std. 1588(TM)-2008. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages", Doug Arnold, Heiko Gerstung, 2015-02-04, This document describes a profile for the use of the Precision Time Protocol in an IPV4 or IPv6 Enterprise information system environment. The profile uses the End to End Delay Measurement Mechanism, allows both multicast and unicast Delay Request and Delay Response Messages. "Multi-Path Time Synchronization", Alex Shpiner, Richard Tse, Craig Schelp, Tal Mizrahi, 2015-04-19, Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. Slave Diversity is a recently introduced approach, where the master and slave clocks (also known as server and client) are connected through multiple network paths, and the slave combines the information received through all paths to obtain a higher clock accuracy compared to the conventional one-path approach. This document describes a multi-path approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks. The multi-path approach can significantly contribute to clock accuracy, security and fault tolerance. The Multi-Path Precision Time Protocol (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an additional layer that extends the existing PTP and NTP without the need to modify these protocols. MPPTP and MPNTP also allow backward compatibility with nodes that do not support the multi-path extension. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Cached Information Extension", Stefan Santesson, Hannes Tschofenig, 2015-03-23, Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. "Secure Password Ciphersuites for Transport Layer Security (TLS)", Dan Harkins, Dave Halasz, 2015-03-24, This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. "The Transport Layer Security (TLS) Protocol Version 1.3", Eric Rescorla, 2015-07-08, This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS", Daniel Kahn Gillmor, 2015-06-01, Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246], as well as the TLS ECC extensions [RFC4492]. "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Alfredo Pironti, Adam Langley, Marsh Ray, 2015-07-05, The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", Yoav Nir, 2015-07-06, This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. "A TLS ClientHello padding extension", Adam Langley, 2015-02-17, This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. "Transport Layer Security (TLS) False Start", Adam Langley, Nagendra Modadugu, Bodo Moeller, 2015-05-07, This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. "The ChaCha20-Poly1305 AEAD Cipher for Transport Layer Security", Adam Langley, Wan-Teh Chang, Nikos Mavrogiannopoulos, Joachim Strombergson, Simon Josefsson, 2015-06-11, This document describes the use of the ChaCha stream cipher with Poly1305 in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. "Curve25519 and Curve448 for Transport Layer Security (TLS)", Simon Josefsson, Manuel Pégourié-Gonnard, 2015-07-06, This document specifies the use of Curve25519 and Curve448 for ephemeral key exchange in the Transport Layer Security (TLS) and Datagram TLS (DTLS) protocols. It updates RFC 5246 (TLS 1.2) and RFC 4492 (Elliptic Curve Cryptography for TLS). Token Binding (tokbind) ----------------------- "The Token Binding Protocol Version 1.0", Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley, 2015-05-29, This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the TLS Token Binding identifiers are only transmitted encrypted and can be reset by the user at any time. "Token Binding over HTTP", Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley, 2015-06-30, This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to a TLS [RFC5246] connection. We describe both _first-party_ as well as _federated_ scenarios. In a first-party scenario, an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate. Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS [RFC5246] connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [TBPROTO] TURN Revised and Modernized (tram) ---------------------------------- "An Origin Attribute for the STUN Protocol", Alan Johnston, Justin Uberti, John Yoakum, Kundan Singh, 2015-02-19, STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts. "Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization", Tirumaleswar Reddy, Prashanth Patil, Ram R, Justin Uberti, 2015-05-13, This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. "TURN Server Auto Discovery", Prashanth Patil, Tirumaleswar Reddy, Dan Wing, 2015-05-20, Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Tirumaleswar Reddy, Alan Johnston, Philip Matthews, Jonathan Rosenberg, 2015-07-06, If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. "Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo Salgueiro, Jonathan Rosenberg, Dan Wing, Rohan Mahy, Philip Matthews, 2015-03-27, Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. "Discovery of path characteristics using STUN", Tirumaleswar Reddy, Dan Wing, Paal-Erik Martinsen, Varun Singh, 2015-04-07, A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. Public Notary Transparency (trans) ----------------------------------- "Certificate Transparency", Ben Laurie, Adam Langley, Emilia Kasper, Eran Messeri, Rob Stradling, 2015-07-06, This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. "Attack Model for Certificate Transparency", Stephen Kent, 2015-07-02, This document describes an attack model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "Coordinated Multicast Trees (CMT) for TRILL", Tissa Senevirathne, Janardhanan Pathangi, Jon Hudson, 2015-03-09, TRILL facilitates loop free connectivity to non-TRILL networks via choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide load sharing based on VLAN with an active-standby model. High performance applications require an active-active load sharing model as discussed in RFC 7379. The Active-Active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge. Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT provides flexibility to RBridges in selecting desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325. "TRILL: RBridge Channel Tunnel Protocol", Donald Eastlake, Mohammed Umair, Li Yizhou, 2015-06-15, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism, called RBridge Channel, that is specified in RFC 7178, for the transmission of typed messages between TRILL switches in the same campus and between TRILL switches and end stations on the same link. This document specifies two optional extensions to the RBridge Channel protocol: (1) A standard method to tunnel a variety of payload types by encapsulating them in an RBridge Channel message; and (2) A method to support security facilities for RBridge Channel messages. This document updates RFC 7178. "TRILL: Interface Addresses APPsub-TLV", Donald Eastlake, Li Yizhou, 2015-06-30, This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses such that all of the addresses in each set designate the same interface (port) and the reporting for such a set of the TRILL switch by which it is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to or by-pass the need for the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses. "TRILL Resilient Distribution Trees", Mingui Zhang, Tissa Senevirathne, Janardhanan Pathangi, Ayan Banerjee, Anoop Ghanwani, 2015-07-02, TRILL protocol provides multicast data forwarding based on IS-IS link state routing. Distribution trees are computed based on the link state information through Shortest Path First calculation. When a link on the distribution tree fails, a campus-wide recovergence of this distribution tree will take place, which can be time consuming and may cause considerable disruption to the ongoing multicast service. This document specifies how to build backup distribution trees to protect links on the primary distribution tree. Since the backup distribution tree is built up ahead of the link failure, when a link on the primary distribution tree fails, the pre-installed backup forwarding table will be utilized to deliver multicast packets without waiting for the campus-wide recovergence. This minimizes the service disruption. This document updates RFC 6325. "TRILL OAM MIB", Deepak Kumar, Samer Salam, Tissa Senevirathne, 2015-06-30, This document specifies the Management Information Base (MIB) for the IETF TRILL (Transparent Interconnection of Lots of Links) OAM objects. "TRILL: Edge Directory Assist Mechanisms", Donald Eastlake, Linda Dunbar, Radia Perlman, Igor Gashinsky, Li Yizhou, 2015-06-20, This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi- destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. "Transparent Interconnection of Lots of Links (TRILL) over IP", Margaret Cullen, Donald Eastlake, Mingui Zhang, Dacheng Zhang, 2015-07-06, The Transparent Interconnection of Lots of Links (TRILL) protocol is implemented by devices called TRILL Switches or RBridges (Routing Bridges). TRILL supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between TRILL switch ports. This document standardizes methods for encapsulating TRILL in IP (v4 or v6) so as to use IP as a TRILL link protocol in a unified TRILL campus. It updates RFC 7177 and RFC 7178. "TRILL Active-Active Edge Using Multiple MAC Attachments", Mingui Zhang, Radia Perlman, Hongjun Zhai, Muhammad Durrani, Sujay Gupta, 2015-02-06, TRILL active-active service provides end stations with flow level load balance and resilience against link failures at the edge of TRILL campuses as described in RFC 7379. This draft specifies a method by which member RBridges in an active- active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges are required to keep multiple locations of one MAC address in one Data Label. Design goals of this specification are discussed in the document. "TRILL: Pseudo-Nickname for Active-Active Access", Hongjun Zhai, Tissa Senevirathne, Radia Perlman, Mingui Zhang, Li Yizhou, 2015-03-09, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides support for flow level multi-pathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (TRILL switch) group providing active-active access to such an end station are represented as a Virtual RBridge. Based on the concept of Virtual RBridge along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations. "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)", Deepak Kumar, Tissa Senevirathne, Norman Finn, Samer Salam, Liang Xia, Hao Weiguo, 2015-05-05, This document presents YANG Data model for TRILL OAM. It extends the Generic YANG model for OAM defined in [GENYANGOAM] with TRILL technology specifics. Table of Contents. "TRILL Distributed Layer 3 Gateway", Hao Weiguo, Li Yizhou, Andrew Qu, Muhammad Durrani, Ponkarthick Sivamurugan, Liang Xia, 2015-07-06, Currently the TRILL protocol provides optimal pair-wise data frame forwarding for layer 2 intra-subnet traffic but not for layer 3 inter- subnet traffic. A centralized gateway solution is typically used for layer 3 inter-subnet traffic forwarding but has the following issues: "TRILL: Clarifications, Corrections, and Updates", Donald Eastlake, Mingui Zhang, Radia Perlman, Ayan Banerjee, Anoop Ghanwani, Sujay Gupta, 2015-06-08, Since publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL has revealed errata in RFC 6325 and areas that could use clarifications or updates. RFCs 7177, 7357, and draft-eastlake-trill- rfc6439bis provide clarifications and updates with respect to Adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous TRILL clarifications, corrections, and updates RFC), updates RFC 7177, updates RFC 7179, and updates RFC 6325. "TRILL Smart Endnodes", Radia Perlman, fangwei hu, Donald Eastlake, Kesava Krupakaran, Ting Liao, 2015-05-24, This draft addresses the problem of the size and freshness of the endnode learning table in edge RBridges, by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "smart endnode". Only the attached RBridge can distinguish a "smart endnode" from a "normal endnode". The smart endnode uses the nickname of the attached RBridge, so this solution does not consume extra nicknames. The solution also enables Fine Grained Label aware endnodes. "Centralized Replication for BUM traffic in active-active edge connection", Hao Weiguo, Li Yizhou, Muhammad Durrani, Sujay Gupta, Andrew Qu, Tao Han, 2015-04-29, In TRILL active-active access scenario, RPF check failure issue may occur when pseudo-nickname mechanism in [TRILLPN] is used. This draft describes a solution to the RPF check failure issue through centralized replication for BUM (Broadcast, Unknown unicast, Mutlicast) traffic. The solution has all ingress RBs send BUM traffic to a centralized node via unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the traffic and forwards the BUM traffic to all destination RBs using a distribution tree established via the TRILL base protocol. To avoid RPF check failure on a RBridge sitting between the ingress RBridge and the centralized replication node, some change of RPF calculation algorithm is required. RPF calculation on each RBridge should use the centralized node as ingress RB instead of the real ingress RBridge of RBv to perform the calculation. "TRILL YANG Data Model", Hao Weiguo, Li Yizhou, Deepak Kumar, Muhammad Durrani, Hongjun Zhai, Liang Xia, 2015-05-26, This document defines a YANG data model for TRILL protocol. "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM) Performance Management", Deepak Kumar, Tissa Senevirathne, Tapraj Singh, Qin Wu, Hao Weiguo, 2015-02-14, This document presents YANG Data model for TRILL OAM PM[TRILL-PM]. It extends the YANG model defined in [GENYANGGOAM] and [TRILLOAMYANG] for TRILL OAM Performance management technology specifics. "TRILL IS-IS MTU Negotiation", Mingui Zhang, Xudong Zhang, Donald Eastlake, Radia Perlman, Vishwas Manral, Somnath Chatterjee, 2015-03-08, The base IETF TRILL protocol has a TRILL campus wide MTU feature, specified in RFC 6325 and RFC 7177, that assures that link status changes can be successfully flooded throughout the campus while being able to take advantage of a campus wide capability to support jumbo packets. This document specifies optional updates to that MTU feature to take advantage, for appropriate link local packets, of link local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. It updates RFC 7177. "TRILL: ARP/ND Optimization", Li Yizhou, Donald Eastlake, Linda Dunbar, Radia Perlman, Igor Gashinsky, 2015-04-01, This document describes mechanisms to optimize the ARP (Address Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL campus. Such optimization reduces packet flooding over a TRILL campus. "TRILL: Data Label based Tree Selection for Multi-destination Data", Li Yizhou, Donald Eastlake, Hao Weiguo, Hao Chen, Naveen Nimmu, Somnath Chatterjee, Sunny Rajagopalan, 2015-07-05, TRILL uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress RBridge for flows regardless of the VLAN, Fine Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on VLAN and/or FGL and/or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast path hardware, the amount of pruning information is multiplied by the number of trees; however, there is a limited capacity for such pruning information. This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast group thus reducing the total amount of pruning information so that it can more easily be accommodated by fast path hardware. "TRILL Support of Point to Multipoint BFD", Mingui Zhang, Juniper Networks, Vengada Govindan, 2015-06-09, Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using an RBridge Channel. Transport Area (tsv) -------------------- "CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Yang Yang, Jon Peterson, 2015-03-05, Network Service Providers (NSPs) are currently considering to deploy Content Delivery Networks (CDNs) within their networks. As a consequence of this development, there is a need for interconnecting these local CDNs. The necessary interfaces for inter-connecting CDNs are currently being defined in the Content Delivery Networks Interconnection (CDNI) WG. This document focuses on the CDNI Footprint & Capabilities Advertisement interface (FCI). Specifically, this document specifies a new Application Layer Traffic Optimization (ALTO) service to facilitate Footprint & Capabilities Advertisement in a CDNI context. "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", Stephen Bensley, Lars Eggert, Dave Thaler, Praveen Balasubramanian, Glenn Judd, 2015-07-07, This memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic. DCTCP uses improved Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow- buffered switches. "Definitions of Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, Senthil Sivakumar, Tom Taylor, 2015-06-16, This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT- MIB. NATV2-MIB can be used for monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN). Transport Area Working Group (tsvwg) ------------------------------------ "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Randall Stewart, Michael Tuexen, Irene Ruengeler, 2015-07-05, The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions required for the SCTP endpoints and the mechanisms for NATs necessary to provide similar features of NAPT in the single-point and multi-point traversal scenario. "Recommendations on Using Assigned Transport Port Numbers", Joseph Touch, 2015-04-24, This document provides recommendations to application and service protocol designers on how to use the assigned transport protocol port number space and when to request a port assignment from IANA. It provides designer guidelines on how to interact with the IANA processes defined in RFC6335, thus serving to complement (but not update) that document. "SCTP-PF: Quick Failover Algorithm in SCTP", Yoshifumi Nishida, Preethi Natarajan, Armando Caro, Paul Amer, Karen E. E. Nielsen, 2015-03-09, One of the major advantages of SCTP is the support of multi-homed communication. A multi-homed SCTP end-point has the ability to withstand network failures by migrating the traffic from an inactive network to an active one. However, if the failover operation as specified in RFC4960 is followed, there can be a significant delay in the migration to the active destination addresses, thus severely reducing the effectiveness of the SCTP failover operation. This document complements RFC4960 by the introduction of a new path state, the Potentially Failed (PF) path state, and an associated new failover operation to apply during a network failure. The algorithm defined is called SCTP Potentially Failed Algorithm, SCTP-PF for short. In addition, the document complements RFC4960 by introducing alternative switchover operation modes for the data transfer path management after the recovery of a failed primary path. These modes can allow improvements in the performance of the operation in some network environments. The implementation of the additional switchover operation modes is an optional part of SCTP-PF. The procedures defined in the document require only minimal modifications to the current specification. The procedures are sender-side only and do not impact the SCTP receiver. "DTLS Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, Randell Jesup, Salvatore Loreto, 2015-01-24, The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single homed. "Network Address Translation (NAT) Behavioral Requirements Updates", Reinaldo Penno, Simon Perreault, Mohamed Boucadair, Kengo Naito, 2015-02-18, This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. "GRE-in-UDP Encapsulation", Edward Crabbe, Lucy Yong, Xiaohu Xu, Tom Herbert, 2015-07-04, This document describes a method of encapsulating network protocol packets within GRE and UDP headers. In this encapsulation, the source UDP port can be used as an entropy field for purposes of load balancing, while the protocol of the encapsulated packet in the GRE payload is identified by the GRE Protocol Type. Usage restrictions apply to GRE-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", Randall Stewart, Michael Tuexen, Salvatore Loreto, Robin Seggelmann, 2015-07-06, The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrary large user messages. However, the sender can not interleave different user messages which causes head of line blocking at the sender side. To overcome this limitation, this document adds a new data chunk to SCTP. Whenever an SCTP sender is allowed to send a user data, it can possibly choose from multiple outgoing SCTP streams. Multiple ways for this selection, called stream schedulers, are defined. Some of them don't require the support of user message interleaving, some do. "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Bob Briscoe, John Kaippallimalil, Patricia Thaler, 2015-03-26, The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. "DSCP and other packet markings for RTCWeb QoS", Subha Dhesikan, Cullen Jennings, Dan Druta, Paul Jones, James Polk, 2015-07-06, Many networks, such as service provider and enterprise networks, can provide treatment for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. "Network Transport Circuit Breakers", Gorry Fairhurst, 2015-03-31, This document explains what is meant by the term "network transport circuit breaker" (CB). It describes the need for circuit breakers when using network tunnels, and other non-congestion controlled applications. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. "Diffserv interconnection classes and practice", Ruediger Geib, David Black, 2015-07-01, This document proposes a limited set of DiffServ PHBs and codepoints to be applied at (inter)connections of two separately administered and operated networks. Many network providers operate MPLS using Treatment Aggregates for traffic marked with different DiffServ PHBs, and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of DiffServ for network interconnection among providers that use MPLS and apply the Short-Pipe tunnel mode. "UDP Usage Guidelines", Lars Eggert, Gorry Fairhurst, Greg Shepherd, 2015-07-07, The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of ECN, DSCPs, and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. If published as an RFC, this document will obsolete RFC5405. Time Zone Data Distribution Service (tzdist) -------------------------------------------- "CalDAV: Time Zones by Reference", Cyrus Daboo, 2015-06-12, This document defines an extension to the CalDAV calendar access protocol to allow clients and servers to exchange iCalendar data without the need to send full time zone data. "Time Zone Data Distribution Service", Michael Douglass, Cyrus Daboo, 2015-06-29, This document defines a time zone data distribution service that allows reliable, secure and fast delivery of time zone data and leap second rules to client systems such as calendaring and scheduling applications or operating systems. Uniform Resource Names, Revised (urnbis) ---------------------------------------- "Uniform Resource Names (URNs)", Peter Saint-Andre, John Klensin, 2015-06-15, A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. "Uniform Resource Name (URN) Namespace Registration Transition", John Klensin, Juna Hakala, 2015-02-16, The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 2141bis]]. That document adopts a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. "URN Semantics Clarification", John Klensin, 2015-02-13, Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Library, Museum, Publisher, and Information Science communities and other users, this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) in RFC 3986, updating that document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. Using TLS in Applications (uta) ------------------------------- "Updated TLS Server Identity Check Procedure for Email Related Protocols", Alexey Melnikov, 2015-06-17, This document describes TLS server identity verification procedure for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces Section 2.4 of RFC 2595. "Deployable Enhanced Email Privacy (DEEP)", Keith Moore, Chris Newman, 2015-07-06, This specification defines a set of requirements and facilities designed to improve email confidentiality between a mail user agent (MUA) and a mail submission or mail access server. This provides mechanisms intended to increase use of already deployed Transport Layer Security (TLS) technology, provide a model for mail user agent's confidentiality assurance, and enable mail service providers to advertise improved TLS confidentiality facilities. IPv6 Operations (v6ops) ----------------------- "Some Design Choices for IPv6 Networks", Philip Matthews, Victor Kuarsingh, 2015-07-06, This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. "Considerations For Using Unique Local Addresses", Bing Liu, Sheng Jiang, 2015-05-03, This document provides considerations for using IPv6 Unique Local Addresses (ULAs). It identifies cases where ULA addresses are helpful as well as potential problems that their use could introduce, based on an analysis of different ULA usage scenarios. "DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration", Bing Liu, Sheng Jiang, Xiangyang Gong, Wendong Wang, Enno Rey, 2015-07-06, The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration. These are the M, O, and A flags. These flags by definition are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that divergent behaviors might cause. "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments", Tore Anderson, 2015-06-28, This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 when reaches the IDC operator's network infrastructure. From that point on, it is treated just as if it was traffic from any other IPv6-capable end user. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. "IPv6 Prefix Length Recommendation for Forwarding", Mohamed Boucadair, Alexandre Petrescu, Fred Baker, 2015-05-26, IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. "SIIT-DC: Dual Translation Mode", Tore Anderson, S.J.M. Steffann, 2015-06-28, This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency. The reader is expected to be familiar with the SIIT-DC architecture described in I-D.ietf-v6ops-siit-dc. "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2015-06-28, This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. "Observations on IPv6 EH Filtering in the Real World", Fernando Gont, J. Linkova, Tim Chown, Shucheng LIU, 2015-04-23, This document presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the Internet (as measured in August 2014), and where in the network such filtering occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community. "Explicit Address Mappings for Stateless IP/ICMP Translation", Tore Anderson, Alberto Leiva, 2015-06-30, This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, Matthew Miller, Philipp Hancke, 2015-03-24, This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server host name (e.g., hosting.example.net), which is especially important in multi-tenanted environments where the same target server hosts a large number of domains. "Extensible Messaging and Presence Protocol (XMPP): Address Format", Peter Saint-Andre, 2015-06-11, This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. "PKIX over Secure HTTP (POSH)", Matthew Miller, Peter Saint-Andre, 2015-02-23, Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. While these methods developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) --------------------------------------------------------------------- "Considerations for Selecting RTCP Extended Report (XR) Metrics for the WebRTC Statistics API", Varun Singh, Rachel Huang, Roni Even, Dan Romascanu, Deng Lingli, 2015-02-28, This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTCP Sender Report, Receiver Report and Extended Report metrics, which may need to be supported by RTP implementations in some diverse environments. It also defines a new IANA registry, a list of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows. "RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications", Rachel Huang, Alan Clark, 2015-07-06, This draft defines a new video loss concealment block type to augment those defined in [RFC3611] and [RFC7294] for use in a range of RTP video applications.