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 2014-06-26 17:08:17 UTC. IPv6 over Networks of Resource-constrained Nodes (6lo) ------------------------------------------------------ "Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy", Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez, 2014-06-11, 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 is standardized since the 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 6LoWPAN techniques. "Transmission of IPv6 packets over ITU-T G.9959 Networks", Anders Brandt, Jakob Buron, 2014-05-04, This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. "6LoWPAN Generic Compression of Headers and Header-like Payloads", Carsten Bormann, 2014-06-19, This short specification provides a simple addition to 6LoWPAN Header Compression that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each new such header or header-like payload. "Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", Jürgen Schönwälder, Anuj Sehgal, Tina Tsou, Cathy Zhou, 2014-04-08, 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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel, 2014-06-19, 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 15 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. IPv6 Maintenance (6man) ----------------------- "Enhanced Duplicate Address Detection", Rajiv Asati, Hemant Singh, Wes Beebee, Eli Dart, Wesley George, Carlos Pignataro, 2014-05-02, Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. "Packet loss resiliency for Router Solicitations", Suresh Krishnan, Dmitry Anipko, Dave Thaler, 2014-04-21, When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intended to work even in such scenarios. "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 2014-04-29, 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 at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that employed for any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations use simple a global counter for setting the Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. "Updates to the IPv6 Multicast Addressing Architecture", Mohamed Boucadair, Stig Venaas, 2014-06-18, This document updates the IPv6 multicast addressing architecture by re-defining the reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. "IPv6 Multicast Address Scopes", Ralph Droms, 2014-06-12, This document updates the definitions of IPv6 multicast scopes. This document updates RFC 4007 and RFC 4291 "Privacy Considerations for IPv6 Address Generation Mechanisms", Alissa Cooper, Fernando Gont, Dave Thaler, 2014-02-14, 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, Will, 2014-01-24, Stateless Address Autoconfiguration (SLAAC) for IPv6 typically results in hosts configuring one or more stable addresses composed of a network prefix advertised by a local router, and an Interface Identifier that typically embeds a hardware address (e.g., an IEEE LAN MAC address). The security and privacy implications of embedding hardware 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 recommends [I-D.ietf-6man-stable-privacy-addresses] as the default scheme for the generating stable IPv6 addresses and recommends against embedding hardware addresses in IPv6 Interface Identifiers. "Analysis of the 64-bit Boundary in IPv6 Addressing", Brian Carpenter, Tim Chown, Fernando Gont, Sheng Jiang, Alex Petrescu, Andrew Yourtchenko, 2014-05-07, The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyses the issues that would be involved in treating it as a variable boundary. IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) -------------------------------------------------- "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", Pascal Thubert, Thomas Watteyne, Robert Assimiti, 2014-06-18, This document presents 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. The TSCH schedule can be static or dynamic. 6TiSCH defines mechanisms to establish and maintain the routing and scheduling operations in a centralized, distributed, or mixed fashion. Backbone Routers perform proxy Neighbor Discovery operations over the backbone on behalf of the wireless devices, so they can share a same subnet and appear to be connected to the same backbone as classical devices "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2014-02-13, 6TiSCH proposes an architecture for an IPv6 multilink 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. "6TiSCH Operation Sublayer (6top) Interface", Qin Wang, Xavier Vilajosana, Thomas Watteyne, 2014-03-27, 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 future network management solutions defined by the 6TiSCH working group. This document also defines a list commands internal to the 6top sublayer. "6TiSCH Resource Management and Interaction using CoAP", Raghuram Sudhaakar, Pouria Zand, 2014-05-06, 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, we need to define how to interact with 6top, control and modify schedules, monitor parameters etc. 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. The goal of the memo is to define 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.wang-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, 2014-02-14, This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, user or machine principals. These principals may be named using an 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-02-13, 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, 2014-02-14, The use of ABFAB-based technologies requires that the identities to be used to authenticate are configured on the 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, and manage the user's identities and credential-to-service mappings. Anyone designing that software 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. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 2014-03-05, Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at looking glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it. 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 basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO Service would primarily be provided by ISPs, other entities such as content service providers could also operate an ALTO Service. Applications that could use this service are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, Stefano Previdi, Michael Scharf, 2014-02-13, 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, security considerations, recommendations for network administrators, and also guidance for application designers using ALTO. "ALTO Server Discovery", Sebastian Kiesel, Martin Stiemerling, Nico Schwan, Michael Scharf, Song Yongchao, 2013-09-09, 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. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. Access Node Control Protocol (ancp) ----------------------------------- "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 2014-01-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). "Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 2014-02-25, This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access and admission control with white and black lists; o conditional access and admission control with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64. Applications Area (app) ----------------------- "Entertainment Identifier Registry (EIDR) URN Namespace Definition", Pierre-Anthony Lemieux, 2014-05-28, Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers. "Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace", Alexander Adolf, Peter Siebert, 2014-05-19, RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updates RFC 5328 with new registrant information. Applications Area Working Group (appsawg) ----------------------------------------- "The 'acct' URI Scheme", Peter Saint-Andre, 2014-01-23, This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. "XML Media Types", Henry Thompson, Chris Lilley, 2014-04-07, This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. "Sieve Email Filtering: Detecting Duplicate Deliveries", Stephan Bosch, 2014-06-26, This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", William Mills, Murray Kucherawy, 2014-04-19, This document defines an extension for the Simple Mail Transfer Protocol called RRVS, to provide a method for senders to indicate to receivers a point in time when the the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. This document also defines a header field called Require-Recipient-Valid-Since that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. "URI Design and Ownership", Mark Nottingham, 2014-05-20, RFC3986 Section 1.1.1 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. "Returning Values from Forms: multipart/form-data", Larry Masinter, 2014-04-28, This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. "A NULL MX Resource Record for Domains that Accept No Mail", John Levine, Mark Delany, 2014-06-18, Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. "IMAP4 Multimailbox SEARCH Extension", Barry Leiba, Alexey Melnikov, 2014-06-03, The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. "Guidelines and Registration Procedures for New URI Schemes", Dave Thaler, Tony Hansen, Ted Hardie, Larry Masinter, 2014-03-31, This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. "Email Authentication Status Codes", Murray Kucherawy, 2014-06-26, There is at present no way to return a status code to an email client that indicates a message is being rejected or deferred specifically because of email authentication failures. This document registers codes for this purpose. Active Queue Management and Packet Scheduling (aqm) --------------------------------------------------- "IETF Recommendations Regarding Active Queue Management", Fred Baker, Gorry Fairhurst, 2014-06-24, This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)", Ray van Brandenburg, Hans Stokking, Oskar van Deventer, Fernando Boronat, Mario Montagud, Kevin Gross, 2013-08-29, This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, Kevin Igoe, 2014-06-24, This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data 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, Dong-Chan Kim, Je-Hong Park, Daesung Kwon, 2013-11-19, 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 three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. "RTP Clock Source Signalling", Aidan Williams, Kevin Gross, Ray van Brandenburg, Hans Stokking, 2014-03-24, NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. "Encrypted Key Transport for Secure RTP", David McGrew, Dan Wing, 2014-02-14, Encrypted Key Transport (EKT) is an extension to Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, Rollover Counters, and other information. This facility enables SRTP to work for decentralized conferences with minimal control. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP, and MIKEY. With EKT, these other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the SRTP keys within the session. "Sending Multiple Types of Media in a Single RTP Session", Magnus Westerlund, Colin Perkins, Jonathan Lennox, 2014-02-14, This document specifies how an RTP session can contain media 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, 2014-02-14, 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, 2014-05-27, 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 is intended to replace RFC 5117. "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", Magnus Westerlund, BoB, Colin Perkins, Harald Alvestrand, 2014-01-13, The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. "Sending Multiple Media Streams in a Single RTP Session", Jonathan Lennox, Magnus Westerlund, Wenson Wu, Colin Perkins, 2014-05-28, This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are using multiple synchronization sources (SSRCs), e.g. for sending multiple media streams, in a single RTP session. In particular, issues involving RTCP Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. It also updates RFC 4585 to update and clarify the calculation of the timeout of SSRCs and the inclusion of feeback 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, 2014-02-14, 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. Audio/Video Transport Extensions (avtext) ----------------------------------------- "A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", Jonathan Lennox, Kevin Gross, Suhas Nandakumar, Gonzalo Salgueiro, BoB, 2014-02-14, 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 relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. "RTP Media Stream Pause and Resume", Azam Akram, BoB, Roni Even, Magnus Westerlund, 2014-05-16, 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. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 2014-02-14, 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, 2014-02-14, 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 12. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Sergio Murillo, 2014-03-26, 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. This document normatively updates [I-D.draft-ietf- bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Tom Nadeau, Zafar Ali, Nobo Akiya, 2014-06-04, 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 for modeling Bidirectional Forwarding Detection (BFD) protocol. "Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management", Tom Nadeau, Zafar Ali, Nobo Akiya, 2014-05-14, This draft defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, Dacheng Zhang, Mahesh Jethanandani, 2014-04-17, This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of arbitrary cryptographic authentication algorithms in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. "BFD for Multipoint Networks", Dave Katz, David Ward, 2014-02-18, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. "BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2013-12-26, 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 BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. "Common Interval Support in BFD", Nobo Akiya, Marc Binderberger, Greg Mirsky, 2014-06-11, Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. "Seamless Bidirectional Forwarding Detection (BFD) Use Case", Sam Aldrin, Manav Bhatia, Greg Mirsky, Nagendra Kumar, Satoru Matsushima, 2014-06-11, This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that simplified solution and extensions could be developed for detecting forwarding failures. "Seamless Bidirectional Forwarding Detection (S-BFD)", Nobo Akiya, Carlos Pignataro, David Ward, Manav Bhatia, Juniper Networks, 2014-06-12, 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. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 2013-01-16, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. This specification updates RFC3261 and RFC4235. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic session setup and registration", Carol Davids, Vijay Gurbani, Scott Poretsky, 2014-05-28, This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document. Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars and Session Border Controllers. The term "performance" in this context means the capacity of the device-under- test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology is necessary because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definition and were obtained following the same procedures. "Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic session setup and registration", Carol Davids, Vijay Gurbani, Scott Poretsky, 2014-05-28, This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document. Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars and Session Border Controllers. The term "performance" in this context means the capacity of the device-under- test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. "Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence", Rajiv Papneja, Bhavani Parise, Susan Hares, Dean Lee, Ilya Varlashkin, 2014-03-02, 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. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku, 2014-02-13, This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 2014-05-21, A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Hao Long, 2014-04-28, The GMPLS controlled Ethernet Label Switching (GELS) work extended GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs, and defines the Ethernet technology specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms. "GMPLS RSVP-TE extensions for OAM Configuration", Attila Takacs, Don Fedyk, He Jia, 2014-02-25, Operations, Administration and Maintenance (OAM) is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/ decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with Label Switched Path signaling. "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. "General Network Element Constraint Encoding for GMPLS Controlled Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 2014-02-05, Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, David Ward, Attila Takacs, 2013-06-20, This specification describes the configuration of pro-active MPLS-TP (MPLS-Transport Profile) Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on [OAM-CONF-FWK]. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, Sugang Xu, Young Lee, Giovanni Martinelli, Hiroaki Harai, 2014-03-05, This memo 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. In addition this memo provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. This document updates [RFC6205] as make it applicable to WSON-LSC capable equipment. "OSPF-TE Extensions for General Network Element Constraints", Fatai Zhang, Young Lee, Jianrui Han, Greg Bernstein, Yunbin Xu, 2014-05-21, Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS. "RSVP-TE Extensions for Associated Bidirectional LSPs", Fei Zhang, Ruiquan Jing, Rakesh Gandhi, 2014-03-02, This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Types in (Extended) ASSOCIATION object. In addition, RSVP extensions allow asymmetric upstream and downstream bandwidths for the bidirectional LSP. "RSVP-TE Extensions for Collecting SRLG Information", Fatai Zhang, Oscar de Dios, Dan Li, Cyril Margaria, Matt Hartley, Zafar Ali, 2014-02-14, 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 LSP. "LSP Attribute in ERO", Cyril Margaria, Giovanni Martinelli, Steve Balls, Ben Wright, 2014-02-13, RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an LSP. This document proposes an extension to the RSVP ERO and RRO objects to allow it to specify or record generic attributes which apply to a given hop. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Gabriele Galimberti, Ori Gerstel, Kenji Kumaki, Ruediger Kunze, Julien Meuric, 2014-02-03, RFC 4874 specifies methods by which path exclusions may be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies signaling for additional route exclusion subobjects 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, 2014-02-14, There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) 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) for the support of the discovery of cost, latency and latency variation of an LSP. "GMPLS RSVP-TE Extensions for Lock Instruct and Loopback", Jie Dong, Mach Chen, Zhenqiang Li, Daniele Ceccarelli, 2014-04-22, This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. "Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks", Oscar de Dios, Ramon Casellas, Fatai Zhang, Xihua Fu, Daniele Ceccarelli, Iftekhar Hussain, 2014-02-14, This document defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks. To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended the recommendations [G.694.1] and [G.872] to include the concept of flexible grid. A new DWDM grid has been developed within the ITU-T Study Group 15 by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum. "Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy, Ramon Casellas, 2014-01-07, The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification [RFC3209] and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions [RFC4874] 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 [RFC3209] and [RFC4874], albeit with a 2-Byte AS number. "Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers", Adrian Farrel, Daniel King, Yao Li, Fatai Zhang, 2014-06-23, 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 de Dios, Daniele Ceccarelli, 2014-06-23, This memo describes the extensions to RSVP-TE signaling to support Label Switched Paths in a GMPLS-controlled network that includes devices using the flexible optical grid. "Link Management Protocol Extensions for Grid Property Negotiation", Yao Li, Guoying Zhang, Xihua Fu, Ramon Casellas, Yu Wang, 2014-06-23, The recent updated version of ITU-T [G.694.1] has introduced 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 de Dios, Daniele Ceccarelli, 2014-06-23, This memo describes the OSPF-TE extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Distribution Network Interconnection (CDNI) Requirements", Kent Leung, Yiu Lee, 2014-01-30, Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. "Framework for CDN Interconnection", Larry Peterson, Bruce Davie, Ray van Brandenburg, 2014-06-06, This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. "CDN Interconnect Metadata", Ben Niven-Jenkins, Rob Murray, Grant Watson, Matt Caulfield, Kent Leung, Kevin Ma, 2014-02-14, The CDNI Metadata Interface enables interconnected 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 the core set of CDNI metadata and the protocol for exchanging that metadata. "CDNI Logging Interface", Francois Le Faucheur, Gilles Bertrand, Iuniana Oprescu, Roy Peterkofsky, 2014-03-25, 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. "Request Routing Redirection Interface for CDN Interconnection", Ben Niven-Jenkins, Ray van Brandenburg, 2014-04-16, The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a 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, 2014-02-14, 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 and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. "URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le Faucheur, Ray van Brandenburg, Bill Downey, Michel Fisher, 2014-06-15, This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. Crypto Forum Research Group (cfrg) ---------------------------------- "Dragonfly Key Exchange", Dan Harkins, 2014-05-12, 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. "Augmented Password-Authenticated Key Exchange (AugPAKE)", SeongHan Shin, Kazukuni Kobara, 2014-02-04, 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). ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 2014-05-15, 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 for setting up a telepresence session. "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano, 2014-06-19, This document formally describes the data model adopted in CLUE. It provides an XML schema file for the definition of CLUE data model types. "CLUE Protocol Data Channel", Christer Holmberg, 2014-03-21, This document defines how to use the WebRTC Data Channel mechanism, together with the Data Channel Establishment Protocol (DCEP) in order to establish a data channel, referred to as CLUE Data Channel, for transporting CLUE protocol messages between two CLUE entities. The document defines the SCTP considerations specific to a CLUE Data Channel, the SDP offer/answer procedures for negotiating the establishment of, and the DCEP procedures for opening, a CLUE Data Channel. Details and procedures associated with the CLUE protocol are outside the scope of this document. "CLUE Signaling", Paul Kyzivat, Lennard Xiao, Christian Groves, Robert Hansen, 2014-05-29, This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-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, 2014-06-24, 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 [I-D.ietf-clue-telepresence-requirements]. The companion document [I-D.kyzivat-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, 2014-02-07, 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. "Updates to the Opus Audio Codec", Jean-Marc Valin, Koen Vos, 2014-01-13, This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716]. Congestion Exposure (conex) --------------------------- "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Matt Mathis, Bob Briscoe, 2014-03-13, This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier 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-02-14, 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, 2014-02-14, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on 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-02-14, This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 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 mobile networks. Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Klaus Hartke, Carsten Bormann, 2013-06-28, The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. "Observing Resources in CoAP", Klaus Hartke, 2014-04-10, 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. "Group Communication for CoAP", Akbar Rahman, Esko Dijk, 2014-06-17, CoAP is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. "Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2014-02-12, This draft provides reference information for HTTP-CoAP protocol translation proxy implementors, focusing primarily on the reverse proxy case. It details deployment options, defines a safe method for URI mapping, and provides a set of guidelines and considerations related to protocol translation. Call Control UUI Service for SIP (cuss) --------------------------------------- "A Mechanism for Transporting User to User Call Control Information in SIP", Alan Johnston, James Rafferty, 2014-06-03, There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. "Interworking ISDN Call Control User Information with SIP", Keith Drage, Alan Johnston, 2014-03-05, The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 2014-02-14, 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, 2014-06-10, The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names 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, 2014-06-23, This memo clarifies and updates the DANE TLSA protocol based on implementation experience since the publication of the original specification [RFC6698]. It also contains guidance for DANE implementers and operators. "SMTP security via opportunistic DANE TLS", Viktor Dukhovni, Wesley Hardaker, 2014-05-25, 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, 2014-04-10, OpenPGP is a message format for email (and file) encryption, that lacks a standarized lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. "Best Common Practise for using OPENPGPKEY records", Paul Wouters, 2014-04-10, The OPENPGPKEY DNS Resource Record can be used to match an email address to an OpenPGP key. This document specifies a Best Common Practise ("BCP") for email clients, MUA's and MTA's for using the OPENPGPKEY DNS Resource Record. Dynamic Host Configuration (dhc) -------------------------------- "DHCPv4 over IPv6 Transport", Yong Cui, Peng Wu, Jianping Wu, Ted Lemon, Qi Sun, 2014-04-23, In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. DHCPv4 over IPv6 has been developed in the IETF, and some implementations and deployments have been carried out. But this mechanism is not recommended for future implementation or deployment. "Issues with multiple stateful DHCPv6 options", Ole Troan, Bernie Volz, 2014-01-01, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in RFC6204 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. This document updates RFC3315 and indirectly RFC3633. "Registering Self-generated IPv6 Addresses in DNS using DHCPv6", Sheng Jiang, Gang Chen, Suresh Krishnan, Rajiv Asati, 2014-06-23, In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. "DHCPv6 Failover Design", Tomek Mrugalski, Kim Kinnear, 2013-09-13, DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not a protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol specification document is planned to follow this document. "DHC Load Balancing Algorithm for DHCPv6", Andre Kostur, 2014-03-02, This document proposes a method of algorithmic load balancing for IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It enables multiple, cooperating servers to decide which one should service a client, without necessarily exchanging any information between the servers. The server selection is based on the servers hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 servers are available to service DHCPv6 clients. The proposed technique provides for efficient server selection when multiple DHCPv6 servers offer services on a network without requiring any changes to existing DHCPv6 clients. This algorithm is an extension of an already defined and proven algorithm used for DHCPv4, as described in RFC 3074. "Handling Unknown DHCPv6 Messages", Yong Cui, Qi Sun, Ted Lemon, 2014-03-27, DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems and defines how a DHCPv6 server, client or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents defining new messages sent from DHCP servers to DHCP relay agents, and should be read by potential authors of such documents. This document updates RFC3315. "DHCPv4 over DHCPv6 Transport", Qi Sun, Yong Cui, Marcin Siodelski, Suresh Krishnan, Ian Farrer, 2014-06-12, IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. "Provisioning IPv4 Configuration Over IPv6 Only Networks", Branimir Rajtar, Ian Farrer, 2014-02-12, As IPv6 becomes more widely adopted, some service providers are choosing to deploy IPv6 only networks without dual-stack functionality for IPv4. However, as access to IPv4 based services will continue to be a requirement for the foreseeable future, IPv4 over IPv6 mechanisms, such as softwire tunnels are being developed. In order to provision end-user's hosts with the IPv4 configuration necessary for such mechanisms, a number of different approaches have been proposed. This memo discusses each of the proposals, identifies the benefits and drawbacks and recommends approaches to be used as the basis for future deployment and development. "Access-Network-Identifier Option in DHCP", Shwetha Bhandari, Sri Gundavelli, Jouni Korhonen, Mark Grayson, 2014-02-13, 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, 2014-02-14, 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 with Public Key", Sheng Jiang, Sean Shen, Dacheng Zhang, Tatuya Jinmei, 2014-06-19, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not 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 communication between DHCPv6 clients and DHCPv6 servers. This mechanism is based on public/private key pairs. The authority of the sender may depend on either pre-configuration mechanism or Public Key Infrastructure. "DHCPv6 Active Leasequery", Dushyant, Kim Kinnear, Deepak Kukrety, 2014-03-28, 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 extends DHCPv6 Bulk Leasequery by adding new options. "Active DHCPv4 Lease Query", Kim Kinnear, Mark Stapp, Bernie Volz, Neil Russell, 2014-06-03, 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. "IP Connectivity Status Notifications for DHCPv6", Prashanth Patil, Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy, 2014-02-04, This specification extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically inform the DHCPv6 server about the IP connectivity status of a host. The IP connectivity status information is also triggered by any change in the connectivity as provided to the host. The DHCPv6 server uses this information as an input to its decision- making about configuration parameters to be conveyed to that host. "Dynamic Allocation of Shared IPv4 Addresses", Yong Cui, Qiong, Ian Farrer, Yiu Lee, Qi Sun, Mohamed Boucadair, 2014-04-04, 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 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 addresses sharing, some limitations to their applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized. DTLS In Constrained Environments (dice) --------------------------------------- "A DTLS 1.2 Profile for the Internet of Things", Klaus Hartke, Hannes Tschofenig, 2014-05-06, This document defines a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Applications Design Guidelines", Lionel Morand, Victor Fajardo, Hannes Tschofenig, 2014-06-04, The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Futhermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand, 2014-02-14, In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers 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 peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. "Diameter Overload Indication Conveyance", Jouni Korhonen, Steve Donovan, Ben Campbell, Lionel Morand, 2014-03-27, This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements "Diameter Congestion and Filter Attributes", Brent Hirschman, Lyle Bertz, 2014-04-18, This document defines optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It 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. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. These optional attributes are forward and backwards compatible with RFC 5777. Distributed Mobility Management (dmm) ------------------------------------- "Requirements for Distributed Mobility Management", Anthony Chan, Dapeng Liu, Pierrick Seite, Hidetoshi Yokota, Jouni Korhonen, 2014-06-05, This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. "Distributed Mobility Management: Current practices and gap analysis", Dapeng Liu, Juan-Carlos Zúñiga, Pierrick Seite, Anthony Chan, Carlos Bernardos, 2014-05-25, The present document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, Joe Abley, 2014-02-14, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS resource records). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone administrators. "Domain Name System (DNS) Cookies", Donald Eastlake, 2014-01-28, DNS cookies are a lightweight DNS transaction security mechanism designed for incremental deployment. They provide limited protection to DNS servers and resolvers 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. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, 2014-02-14, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "AS112 Redirection using DNAME", Joe Abley, Brian Dickson, Warren Kumari, George Michaelson, 2014-03-19, Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily. "Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.", Mark Andrews, 2014-05-06, 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. "Automating DNSSEC Delegation Trust Maintenance", Warren Kumari, Olafur Gudmundsson, George Barwood, 2014-06-10, This document describes a method to allow DNS operators to more easily update DNSSEC Key Signing Keys using the DNS as communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the child to parent. "Child To Parent Synchronization in DNS", Wesley Hardaker, 2014-05-13, This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that it may copy and process certain records from the child zone. The existence of and value change of the record may be monitored by a parental agent and acted on as appropriate. "DNSSEC Roadblock Avoidance", Wesley Hardaker, Olafur Gudmundsson, Suresh Krishnaswamy, 2014-03-07, 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. "AS112 Nameserver Operations", Joe Abley, William Maton, 2014-06-20, Many sites connected to the Internet make use of IPv4 addresses that are not globally-unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. RFC6304 described the steps required to install a new AS112 node, and offered advice relating to such a node's operation. This document updates that advice to facilitate the addition and removal of zones for which query traffic will be sunk at AS112 nodes, using DNAME, whilst still supporting direct delegations to AS112 name servers. This document obsoletes RFC6304. "The edns-tcp-keepalive EDNS0 Option", Paul Wouters, Joe Abley, 2014-04-11, 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 are currently limited in their use of the TCP transport as RFC 5966 suggests closing idle TCP sessions "in the order of seconds", making use of TCP only suitable for individual queries generated as a fallback protocol for truncated UDP answers. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS clients and servers to signal their respective readiness to conduct multiple DNS transactions over individual TCP sessions. 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, 2014-04-11, This document defines an EDNS0 extension that can be used by a DNSSEC enabled Recursive Nameserver configured as a forwarder to send a single DNS query requesting to receive a complete validation path along with the regular DNS answer, without the need to rapid-fire many UDP requests in an attempt to attain a low latency. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------------ "Requirements for Scalable DNS-SD/mDNS Extensions", Kerry Lynn, Stuart Cheshire, Marc Blanchet, Daniel Migault, 2014-06-09, DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. 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-04-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, 2014-04-22, This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session establishment. Delay-Tolerant Networking Research Group (dtnrg) ------------------------------------------------ "Streamlined Bundle Security Protocol Specification", Edward Birrane, 2014-05-27, This document defines a streamlined bundle security protocol, which provides data authentication, integrity, and confidentiality services for the Bundle Protocol. Capabilities are provided to protect the bundle payload, and additional data that may be included within the bundle, along a single path through a network. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Trustworthy Location", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 2014-06-02, The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document describes threats relating to conveyance of location in an emergency call, and describes techniques that improve the reliability and security of location information conveyed in a IP- based emergency service call. It also provides guidelines for assessing the trustworthiness of location information. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, Dirk Kroeselberg, 2013-10-19, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. With features provided by the Public Switched Telephone Network (PSTN) there is precedence for some of these use cases and the transition to IP-based emergency calling creates the desire to replicate functionality the PSTN already offers today. For example, in many countries persons seeking help are empowered to initiate emergency calls without having a Subscriber Identity Module (SIM) in their mobile phone. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 2014-02-14, RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. "Additional Data related to an Emergency Call", Brian Rosen, Hannes Tschofenig, Roger Marshall, Randy, James Winterbottom, 2014-04-23, When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. "Policy for defining new service-identifying labels", Andrea Forte, Henning Schulzrinne, 2014-05-30, In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. Energy Management (eman) ------------------------ "Energy Management Framework", Benoit Claise, Brad Schoening, Juergen Quittek, 2014-04-28, This document defines a framework for Energy Management for devices and device components within or connected to communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally the framework models relationships and capabilities between Energy Objects. "Energy Object Context MIB", John Parello, Benoit Claise, Mouli Chandramouli, 2014-06-11, This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices. "Definition of Managed Objects for Battery Monitoring", Juergen Quittek, Rolf Winter, Thomas Dietz, 2014-03-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. "Power and Energy Monitoring MIB", Mouli Chandramouli, Benoit Claise, Brad Schoening, Juergen Quittek, Thomas Dietz, 2014-06-10, This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. "Energy Management (EMAN) Applicability Statement", Brad Schoening, Mouli Chandramouli, Bruce Nordman, 2014-06-24, The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. 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) ---------------------------------------------------- "Extension Registry for the Extensible Provisioning Protocol", Scott Hollenbeck, 2014-06-24, The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. "Key Relay Mapping for the Extensible Provisioning Protocol", R. Gieben, M. Groeneweg, Rik Ribbers, Antoin Verschuren, 2014-01-19, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the purpose of relaying DNSSEC key material from one DNS operator to another, by using the administrative registration channel through the registrant, registrar and registry. The mapping introduces "" as a new command in EPP. This command 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, 2014-03-17, 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, 2014-01-27, 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, 2014-01-27, 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. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Protocol Extensions", Jamal Hadi Salim, 2014-06-03, Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes extensions to the ForCES Protocol Specification[RFC 5810] semantics to achieve that end goal. "ForCES Model Extension", Evangelos Haleplidis, 2014-05-20, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document extends the model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with LFB inheritance. The document also introduces two new features a new event condition BecomesEqualTo and LFB properties. "ForCES Packet Parallelization", Evangelos Haleplidis, Joel Halpern, 2014-02-15, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. 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. "Process Experiment: Document Shepherding Throughout a Document's Lifecycle", Barry Leiba, 2014-05-16, RFC 4858 talks about "Document Shepherding from Working Group Last Call to Publication". There's a significant part of a document's life that happens before working group last call, starting at the time that a working group begins discussing a version of the idea that's been posted as an individual draft. This document extends RFC 4858, discussing the potential for extending shepherding and what tasks might be involved throughout a working group document's lifecycle, from start to finish. "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. Geographic Location/Privacy (geopriv) ------------------------------------- "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 2014-01-22, The key concepts of uncertainty and confidence as they pertain to location information are defined. Methods for the manipulation of location estimates that include uncertainty information are outlined. Global Routing Operations (grow) -------------------------------- "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Keyur Patel, Clarence Filsfils, 2014-01-28, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. "Route-Leaks & MITM Attacks Against BGPSEC", Danny McPherson, Shane Amante, Eric Osterweil, Dave Mitchell, 2014-04-30, This document describes a very simple attack vector that illustrates how RPKI-enabled BGPSEC machinery as currently defined can be easily circumvented in order to launch a Man In The Middle (MITM) attack via BGP. It is meant to serve as input to the IETF's Global Routing Operations Working group (GROW) during routing security requirements discussions and subsequent specification. "IRR & Routing Policy Configuration Considerations", Danny McPherson, Shane Amante, Eric Osterweil, Larry Blunk, Dave Mitchell, 2014-04-30, 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. "The "import-via" and "export-via" attributes in RPSL Policy Specifications", Job Snijders, 2014-03-10, 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. "Internet Exchange Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 2014-03-03, 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 of IXP participation and these systems used by many IXP participants as a preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. "Making BGP filtering a habit: Impact on policies", Camilo Cardona, Pierre Francois, Paolo Lucente, 2014-02-13, Network operators define their BGP policies based on the business relationships that they maintain with their peers. By limiting the propagation of BGP prefixes, an autonomous system avoids the existence of flows between BGP peers that do not provide any economical gain. This draft describes how unexpected traffic flows can emerge in autonomous systems due to the filtering of overlapping BGP prefixes by neighboring domains. "The "import-via" and "export-via" attributes in RPSL Policy Specifications", Job Snijders, 2014-06-06, 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. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Lars Eggert, 2014-03-10, 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, 2014-06-09, 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, 2014-04-24, 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. "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", Julien Laganier, Francis Dupont, 2014-06-25, This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes RFC4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Julien Laganier, 2014-01-15, 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 Identity Protocol Version 2 (HIPv2)", Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson, 2013-10-06, This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 2014-06-23, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", Petri Jokela, Robert Moskowitz, Jan Melen, 2013-11-18, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202. Home Networking (homenet) ------------------------- "IPv6 Home Networking Architecture Principles", Tim Chown, Jari Arkko, Anders Brandt, Ole Troan, Jason Weil, 2014-06-12, This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. "Home Networking Control Protocol", Markus Stenberg, Steven Barth, 2014-06-25, This document describes the Home Networking Control Protocol (HNCP), a minimalist state synchronization protocol for Homenet routers. Hypertext Transfer Protocol Authentication (httpauth) ----------------------------------------------------- "HTTP Origin-Bound Authentication (HOBA)", Stephen Farrell, Paul Hoffman, Michael Thomas, 2014-04-18, HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require any server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords. "An Encoding Parameter for HTTP Basic Authentication", Julian Reschke, 2014-03-04, The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation, using a new authentication scheme parameter. "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2014-04-24, 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 Digest Access Authentication", Rifaat Shekh-Yusef, David Ahrens, Sophie Bremer, 2014-04-26, 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 may be used with the authentication mechanism. Hypertext Transfer Protocol (httpbis) ------------------------------------- "Hypertext Transfer Protocol version 2", Mike Belshe, Roberto Peon, Martin Thomson, 2014-06-17, This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. "HPACK - Header Compression for HTTP/2", Roberto Peon, Herve Ruellan, 2014-06-17, This specification defines HPACK, a compression format for efficiently representing HTTP header fields in the context of HTTP/2. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; that specific to HTTP/2 are at . The changes in this draft are summarized in Appendix A.1. "HTTP Alternative Services", Mark Nottingham, Patrick McManus, Julian Reschke, 2014-04-01, 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 Encryption for HTTP URIs", Mark Nottingham, Martin Thomson, 2014-06-14, This describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "Compression Extensions for WebSocket", Takeshi Yoshino, 2014-05-12, This document specifies 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 non-control WebSocket messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined 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) -------------------------------------- "Use Cases for an Interface to BGP Protocol", Keyur Patel, Rex Fernando, Hannes Gredler, Shane Amante, Russ White, Susan Hares, 2014-06-17, 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. "An Architecture for the Interface to the Routing System", Alia Atlas, Joel Halpern, Susan Hares, David Ward, Tom Nadeau, 2014-06-23, 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 I2RS. "Interface to the Routing System Problem Statement", Alia Atlas, Tom Nadeau, David Ward, 2014-06-23, 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, 2014-05-27, 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. Internet Architecture Board (iab) --------------------------------- "Technical Considerations for Internet Service Blocking and Filtering", Richard Barnes, Alissa Cooper, Olaf Kolkman, 2014-01-29, 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. "The IEEE 802/IETF Relationship", Spencer Dawkins, Patricia Thaler, Dan Romascanu, Bernard Aboba, 2014-02-13, This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronic Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441. Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and is to be reviewed and approved by the IEEE 802 Executive Committee prior to publication. "DNS Root Name Service Protocol and Deployment Requirements", Marc Blanchet, Lars-Johan Liman, 2014-02-11, 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. "A Framework for Describing the Internet Assigned Numbers Authority(IANA)", Olaf Kolkman, 2014-03-19, This document provides a framework for describing the management of Internet registries managed by the Internet Assigned Numbers Authority. It defines terminology describing the various roles and responsibilities associated with management of Internet registry functions. [ Note: This is a work in progress and documents the thoughts developed by the IAB in its IAB iana-evolution program ( http:// www.iab.org/activities/programs/iana-evolution-program/) InternetGovtech@iab.org is the list which the IAB will be monitoring for the discussion of this draft. See http://www.iab.org/mailman/ listinfo/internetgovtech for subscription details. ] "Guidelines for Cryptographic Algorithm Agility", Russ Housley, 2014-01-08, Many IETF protocols may use of cryptographic algorithms to provide confidentiality, integrity, or non-repudiation. Communicating peers must support the same cryptographic algorithm or algorithms for these mechanisms to work properly. This memo provides guidelines for ensuring that such a protocol has the ability to migrate from one algorithm to another over time. "Assigning Digital Object Identifiers to RFCs", John Levine, 2014-02-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 propose a method to assign DOIs to past and future RFCs. "Report from the IAB workshop on Internet Technology Adoption and Transition (ITAT)", Eliot Lear, 2014-06-02, This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass. This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration. 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. "STRINT workshop report", Stephen Farrell, Rigo Wenning, Bert Bos, Marc Blanchet, Hannes Tschofenig, 2014-04-28, The 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. Information-Centric Networking (icnrg) -------------------------------------- "Information-centric Networking: Baseline Scenarios", Kostas Pentikousis, Borje Ohlman, Daniel Corujo, Gennaro Boggia, Gareth Tyson, Elwyn Davies, Antonella Molinaro, Suyong Eum, 2014-03-02, This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence. "Adaptive Video Streaming over ICN", Stefan Lederer, cedric.westphal@huawei.com, Christopher Mueller, Andrea Detti, Daniel Corujo, Christian Timmerer, Daniel Posch, aytav.azgin, 2014-03-11, This document presents the usage of Information Centric Networks (ICN) for adaptive multimedia streaming and identifies problems, which have to be considered for such applications. Several topics related to video distribution over ICN are presented: DASH over ICN, which leverages the recent ISO/IEC MPEG Dynamic Adaptive Streaming over HTTP (DASH) standard, layered encoding over ICN, PPSP over ICN and IPTV over ICN. DASH over ICN offers the possibility to transfer data from multiple sources as well as over multiple links in parallel, which is definitely an important feature, e.g., for mobile devices offering multiple network links. In addition to this, the named multimedia content is routed and cached efficiently by the underlying network. Finally, PPSP extends the P2P semantics to video streaming in ICNs. Inter-Domain Routing (idr) -------------------------- "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 2014-01-23, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. "Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4)", Jeffrey Haas, 2014-01-23, This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. "The Accumulated IGP Metric Attribute for BGP", Prodosh Mohapatra, Rex Fernando, Eric Rosen, Jim Uttaro, 2014-04-28, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "Best Practices for Advertisement of Multiple Paths in IBGP", Jim Uttaro, Pierre Francois, Roberto Fragassi, Adam Simpson, Keyur Patel, Prodosh Mohapatra, 2014-01-27, Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. "Assigned BGP extended communities", Bruno Decraene, Pierre Francois, 2014-06-10, This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. "Dissemination of Flow Specification Rules for IPv6", Robert Raszuk, Burjiz Pithawala, Danny McPherson, Andy, 2014-03-20, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "Enhanced Route Refresh Capability for BGP-4", Keyur Patel, Enke Chen, Balaji Venkatachalapathy, 2014-06-10, In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. This document updates RFC 2918. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, 2014-01-02, [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. "Extended Message support for BGP", Keyur Patel, David Ward, Randy Bush, 2014-01-27, 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, 2014-06-10, The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] 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, 2014-06-13, 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 as 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, 6368 and 6790. "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. "Accelerated Routing Convergence for BGP Graceful Restart", Keyur Patel, Enke Chen, Rex Fernando, John Scudder, 2014-02-05, In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 2014-06-03, 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, 2014-04-09, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. "Internet Exchange Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 2014-06-09, 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. "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro, Clarence Filsfils, David Smith, Juan Alcaide, Pradosh Mohapatra, 2014-01-17, This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray, 2014-05-22, 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, 2014-04-30, Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, 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, Adam Simpson, Wim Henderickx, 2014-04-17, 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. "Multicast Distribution Reachability Signaling", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-01-22, This document describes a mechanism whereby a subscriber's Internet service provider may signal in BGP the ability of the subscriber network to receive content using multicast connectivity. This mechanism is called Multicast Distribution Reachability Signaling (MDRS). "Multicast Distribution Control Signaling", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-01-22, This document describes a mechanism whereby the BGP Flow Specification NLRI format may be utilized to distribute multicast Control Plane filters. This mechanism is called Multicast Distribution Control Signaling (MDCS). "Reservation of Last Autonomous System (AS) Numbers", Jeffrey Haas, Jon Mitchell, 2014-05-20, This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. This document updates section 10 of RFC 1930. "Enhanced Route Refresh Implementation Report", Balaji Venkatachalapathy, Keyur Patel, Robert Raszuk, Prashant Hiremath, 2014-01-09, This document provides an implementation report for Enhanced Route refresh as defined in draft-ietf-idr-bgp-enhanced-route-refresh. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. "BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics", Qin Wu, Wang Danhua, Stefano Previdi, Hannes Gredler, Saikat Ray, 2014-01-12, 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, 2014-01-24, 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. "Multicast Distribution Reachability Signaling", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-02-04, This document describes a mechanism whereby a subscriber's Internet service provider may signal in BGP the ability of the subscriber network to receive content using multicast connectivity. This mechanism is called Multicast Distribution Reachability Signaling (MDRS). "Multicast Distribution Control Signaling", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-02-05, This document describes a mechanism whereby the BGP Flow Specification NLRI format may be utilized to distribute multicast Control Plane filters. This mechanism is called Multicast Distribution Control Signaling (MDCS). "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Wesley George, Shane Amante, 2014-06-13, This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. "Clarification of the Flowspec Redirect Extended Community", Jeffrey Haas, 2014-04-01, This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Chris Pearce, James Polk, Gonzalo Salgueiro, 2014-04-09, 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 "in the wild" session identifier implementation that is sufficiently different from the procedures defined in this document. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, 2014-03-03, 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. Internet Area (int) ------------------- "Mesh Link Establishment", Richard Kelsey, 2014-05-23, 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) detecting neighboring devices. MLE operates below the routing layer, insulating it from the details of configuring, securing, and maintaining individual radio links within a larger mesh network. IP Flow Information Export (ipfix) ---------------------------------- "Exporting MIB Variables using the IPFIX Protocol", Paul Aitken, Benoit Claise, Colin McDowall, Jürgen Schönwälder, 2014-03-04, 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 Option Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB Objects. "Textual Representation of IPFIX Abstract Data Types", Brian Trammell, 2014-06-24, This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. IP Performance Metrics (ippm) ----------------------------- "Test Plan and Results for Advancing RFC 2680 on the Standards Track", Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 2014-04-03, This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2680 on One-way Loss Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680. "A One-Way Delay Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 2014-04-14, 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. "A One-Way Loss Metric for IPPM", Guy Almes, Matthew Zekauskas, Al Morton, 2014-02-13, 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. "Differentiated Service Code Point and Explicit Congestion Notification Monitoring in Two-Way Active Measurement Protocol (TWAMP)", Jonas Hedin, Greg Mirsky, Steve Baillargeon, 2014-03-31, This document describes an OPTIONAL feature for TWAMP [RFC5357] allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol. "Model Based Bulk Performance Metrics", Matt Mathis, Al Morton, 2014-02-14, We introduce a new class of model based metrics designed to determine if an end-to-end Internet path can meet predefined transport performance targets by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests are designed to accurately detect if any subpath will prevent the full end-to-end path from meeting the specified target performance. Each IP diagnostic test consists of a precomputed traffic pattern and a statistical criteria for evaluating packet delivery. The IP diagnostics tests are based on traffic patterns that are precomputed to mimic TCP or other transport protocol over a long path but are independent of the actual details of the subpath under test. Likewise the success criteria depends on the target performance and not the actual performance of the subpath. This makes the measurements open loop, eliminating nearly all of the difficulties encountered by traditional bulk transport metrics. This document does not fully define diagnostic tests, but provides a framework for designing suites of diagnostics tests that are tailored the confirming the target performance. By making the tests open loop, we eliminate standards congestion control equilibrium behavior, which otherwise causes every measured parameter to be sensitive to every component of the system. As an open loop test, various measurable properties become independent, and potentially subject to an algebra enabling several important new uses. Interim DRAFT Formatted: Fri Feb 14 14:07:33 PST 2014 "Network Performance Measurement for IPsec", Kostas Pentikousis, Yang Cui, Emma Zhang, 2014-06-05, The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance in a standardized manner. This document discusses the use of keys derived from an IKEv2 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. "A Reference Path and Measurement Points for LMAP", Marcelo Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton, 2014-06-19, This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. The methods for measurement point location may be applicable to similar measurement projects using the extensions described here. "Advanced Stream and Sampling Framework for IPPM", Joachim Fabini, Al Morton, 2014-05-28, To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. "UDP Checksum Trailer in OWAMP and TWAMP", Tal Mizrahi, 2014-06-25, 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 Trailer, 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. "Active Performance Metric Sub-Registry", Al Morton, Marcelo Bagnulo, Philip Eardley, 2014-04-03, This memo defines the Active Performance Metrics sub-registry of the Performance Metric Registry. This sub-registry will contain Active Performance Metrics, especially those defined in RFCs prepared in the IP Performance Metrics (IPPM) Working Group of the IETF, and possibly applicable to other IETF metrics. Three aspects make IPPM metric registration difficult: (1) Use of the Type-P notion to allow users to specify their own packet types. (2) Use of flexible input variables, called Parameters in IPPM definitions, some of which determine the quantity measured and others of which should not be specified until execution of the measurement. (3) Allowing flexibility in choice of statistics to summarize the results on a stream of measurement packets. This memo proposes a way to organize registry entries into columns that are well-defined, permitting consistent development of entries over time (a column may marked NA if it is not applicable for that metric). The design is intended to foster development of registry entries based on existing reference RFCs, whilst each column serves as a check-list item to avoid omissions during the registration process. Every entry in the registry, before IANA action, requires Expert review as defined by concurrent IETF work in progress "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- registry). The document contains two examples: a registry entry for an active Performance Metric entry based on RFC3393 and RFC5481, and a registry entry for an end-point Performance Metric based on RFC 7003. The examples are for Informational purposes and do not create any entry in the IANA registry. "Passive Performance Metrics Sub-Registry", Aamer Akhter, Benoit Claise, 2014-04-07, This memo defines the Passive Performance Metrics sub-registry of the Performance Metric Registry. This sub-registry will contain Passive Performance Metrics, especially those defined in RFCs prepared in the IP Performance Metrics (IPPM) Working Group of the IETF, and possibly applicable to other IETF metrics. IPPM Passive metric registration is meant to allow wider adoption of common metrics in an inter-operable way. There are challenges with metric interoperability and adoption (to name a few) due to flexible input parameters, confusion between many similar metrics, and varying output formats. This memo proposes a way to organize registry entries into columns that are well-defined, permitting consistent development of entries over time (a column may be marked NA if it is not applicable for that metric). The design is intended to foster development of registry entries based on existing reference RFCs, whilst each column serves as a check-list item to avoid omissions during the registration process. Every entry in the registry, before IANA action, requires Expert review as defined by concurrent IETF work in progress "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- registry). The document contains example entries for the Passive Performance Metrics sub-registry: a registry entry for a passive metric based on octetTotalCount as defined in RFC5102 and a protocol specific passive metric based on RTP packets lost as defined in RFC3550. The examples are for Informational purposes and do not create any entry in the IANA registry. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Signature Authentication in IKEv2", Tero Kivinen, Joel Snyder, 2014-05-07, The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", David McGrew, Paul Hoffman, 2014-05-16, This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. "IKEv2 Fragmentation", Valery Smyslov, 2014-06-09, This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. "Internet Key Exchange Protocol Version 2 (IKEv2)", Charlie Kaufman, Paul Hoffman, Yoav Nir, Pasi Eronen, Tero Kivinen, 2014-06-06, This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Extended Sequence number TLV", Uma Chunduri, Wenhu Lu, Albert Tian, Naiming Shen, 2014-02-13, 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, 2014-04-26, 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. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Jeff Tantsura, 2014-02-13, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing. "IS-IS Flooding Scope LSPs", Les Ginsberg, Stefano Previdi, Yi Yang, 2014-06-04, Intermediate System To Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers. However the current flooding scopes are limited to either area wide scope or domain wide scope. There are existing use cases where support of other flooding scopes are desirable. This document defines new Protocol Data Units (PDUs) which provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended TLVs and sub-TLVs which are encoded using 16 bit fields for type and length. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. "IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno Decraene, Jeff Tantsura, 2014-06-18, 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. "Updates to IS-IS TLV Codepoints Registry", Les Ginsberg, 2014-05-22, This document recommends some editorial changes to the IANA IS-IS TLV Codepoints registry to more accurately document the state of the protocol. It also defines early allocation procedures for codepoints managed by the registry. "Updates to IS-IS TLV Codepoints Registry", Les Ginsberg, 2014-06-11, This document recommends some editorial changes to the IANA IS-IS TLV Codepoints registry to more accurately document the state of the protocol. It also defines early allocation procedures for codepoints managed by the registry. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Web Encryption (JWE)", Michael Jones, Joe Hildebrand, 2014-06-20, JSON Web Encryption (JWE) represents encrypted content using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. "JSON Web Key (JWK)", Michael Jones, 2014-06-20, A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. "JSON Web Algorithms (JWA)", Michael Jones, 2014-06-20, The JSON Web Algorithms (JWA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. "JSON Web Signature (JWS)", Michael Jones, John Bradley, Nat Sakimura, 2014-06-20, JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. "Examples of Protecting Content using JavaScript Object Signing and Encryption (JOSE)", Matthew Miller, 2014-04-21, A set of examples of using JavaScript Object Signing and Encryption (JOSE) to protect data. This document illustrates a representative sampling of various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs. JavaScript Object Notation (json) --------------------------------- "JavaScript Object Notation (JSON) Text Sequences", Nicolas Williams, 2014-05-23, This document describes the JSON text sequence format and associated media type. "The I-JSON Message Format", Tim Bray, 2014-06-13, I-JSON is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 2014-01-13, Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. "A set of SASL Mechanisms for OAuth", William Mills, Tim Showalter, Hannes Tschofenig, 2014-03-06, 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. "Kerberos Authorization Data Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, Thomas Hardjono, 2014-05-08, Abstract: 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. "Move Kerberos protocol parameter registries to IANA", Tom Yu, 2014-02-14, The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. "Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)", Jim Schaad, Larry Zhu, Jeffrey Altman, 2014-02-14, This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. "AES Encryption with HMAC-SHA2 for Kerberos 5", Michael Jenkins, Michael Peck, Kelley Burgin, 2014-05-06, This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. "Anonymity Support for Kerberos", Larry Zhu, Paul Leach, Sam Hartman, 2014-03-03, This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as historic. RFC 6112 contained errors and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", Shawn Emery, Nicolas Williams, 2014-04-28, 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 was underspecified, leading to interoperability problems. "Structure of the GSS Negotiation Loop", Benjamin Kaduk, 2014-05-10, This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. "Generic Security Service API Version 2: Java Bindings Update", Mayank Upadhyay, Seema Malkani, Wang Weijun, 2014-05-29, 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). Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer Schatzmayr, Wim Henderickx, 2014-04-03, This document describes a simple L2 Ethernet over IPv6 tunnel encapsulation with mandatory 64-bit key for connecting L2 Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on L2TPv3 over IP. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "IP-Only LAN Service (IPLS)", Himanshu Shah, Eric Rosen, Francois Le Faucheur, Giles Heron, 2014-06-04, A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. The original intent was to provide an alternate solution to VPLS for those PE routers that were not capable of learning MAC address through data plane. This became non-issue with newer hardware. The concepts put forth by this draft are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN Working Group and possible data center applications. At this point, no further action is planned to update this document and is published simply as a historic record of the ideas. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, Peter Busschbach, David Allan, Monique Morrow, Tom Nadeau, 2014-03-12, This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). "PIM Snooping over VPLS", Olivier Dornon, Jayant Kotalwar, Venu Hemige, Ray Qiu, 2014-04-29, This document describes the procedures and recommendations for VPLS PEs to facilitate replication of multicast traffic to only certain ports (behind which there are interested PIM routers and/or IGMP hosts) via PIM Snooping and PIM Proxy. With PIM Snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM Proxy, 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 Proxy is required when PIM Join suppression is enabled on the 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 proxy, 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. "Virtual Private Lan Services (VPLS) Management Information Base", Tom Nadeau, Kiran Koushik, Rohit Mediratta, 2014-02-21, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with The Pseudowire (PW) Management Information Base. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, Florin Balus, Olen Stokes, Don Fedyk, Geraldine Calvginac, 2014-06-03, RFC4762 describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List from RFC4762, which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC4762 MAC Withdrawal procedures are specified to provide optimized MAC flushing for the Provider Backbone Bridging (PBB)VPLS specified in RFC7041. "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", Raymond Key, Frederic JOUNAY, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, Mach Chen, Lizhong Jin, 2014-01-20, 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. "A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network", Raymond Key, Lucy Yong, Simon DeLord, Frederic JOUNAY, Lizhong Jin, 2014-05-22, This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. "BGP MPLS Based Ethernet VPN", Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac, Jim Uttaro, 2014-05-07, This document describes procedures for BGP MPLS based Ethernet VPNs (EVPN). "PBB-EVPN", Ali Sajassi, Samer Salam, Nabil Bitar, Aldrin Isaac, Wim Henderickx, Lizhong Jin, 2014-06-19, This document discusses how Ethernet Provider Backbone Bridging [802.1ah] can be combined with 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 and B-MAC sub- netting, 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 "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)", Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi, 2014-04-07, A generic Virtual Private LAN Service (VPLS) solution is proposed 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. "Redundancy Mechanism for Inter-domain VPLS Service", Zhihua Liu, Lizhong Jin, Ran Chen, Dennis Cai, Samer Salam, 2014-05-16, In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains. "Shortest Path Bridging, MAC mode Support over EVPN", David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi, 2014-04-21, This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) can be combined with EVPN in a way that interworks with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the different variations of Ethernet networks. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "BGP ACCEPT_OWN Community Attribute", Jim Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 2014-05-28, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as 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, allowing the technique to be used in a standard manner throughout an autonomous system. "MVPN: Using Bidirectional P-Tunnels", Eric Rosen, IJsbrand Wijnands, Yiqun Cai, Arjen Boers, 2014-06-02, A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast "auto-discovery" routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel attribute". Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", IJsbrand Wijnands, Eric Rosen, Uwe Joorde, 2014-05-20, Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. "Extranet Multicast in BGP/IP MPLS VPNs", Yakov Rekhter, Eric Rosen, Rahul Aggarwal, Yiqun Cai, Wim Henderickx, Thomas Morin, Praveen Muley, Ray Qiu, IJsbrand Wijnands, 2014-03-14, 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, 2014-05-12, 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. "Covering Prefixes Outbound Route Filter for BGP-4", Huajin Jeng, Luay Jalil, Ron Bonica, Yakov Rekhter, Keyur Patel, Lucy Yong, Xiaohu Xu, 2014-05-06, This document defines a new ORF-type, called the "Covering Prefixes ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) Networks. "BGP as an MVPN PE-CE Protocol", Keyur Patel, Yakov Rekhter, Eric Rosen, 2014-03-31, 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. "Ingress Replication Tunnels in Multicast VPN", Eric Rosen, Karthik Subramanian, Jeffrey Zhang, 2014-04-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, 2014-02-05, 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. "Virtual Subnet: A L3VPN-based Subnet Extension Solution", Xiaohu Xu, Robert Raszuk, Susan Hares, Fan Yongbing, Christian Jacquenet, Truman Boyes, Brendan Fee, 2014-03-03, This document describes a Layer3 Virtual Private Network (L3VPN)- based subnet extension solution referred to as Virtual Subnet, which can be used as a kind of Layer3 network virtualization overlay approach for data center interconnect. "Inter-AS Option D for BGP/MPLS IP VPN", Manu Pathak, Keyur Patel, Arjun Sreekantiah, 2014-04-09, 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. "IANA registry for PMSI Tunnel Type code points", Loa Andersson, George Swallow, 2014-06-11, RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However the RFC did not create an IANA registry for these. There now is need to make further code point allocations from this name space. This document serves to create an IANA registry for that purpose. "Global Table Multicast with BGP-MVPN Procedures", Jeffrey Zhang, Leonard Giuliano, Eric Rosen, Karthik Subramanian, Dante Pacella, Jason Schiller, 2014-06-24, 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. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP EID Block", Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller, 2014-01-31, 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, 2014-04-23, 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, 2014-04-08, This document proposes a threat analysis of the Locator/Identifier Separation Protocol (LISP) if deployed in the Internet. "LISP Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job Snijders, 2014-05-06, 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 EID Block Management Guidelines", Luigi Iannone, Roger Jorgensen, David Conrad, 2014-02-14, This document proposes an allocation framework for the management of the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]). The framework described relies on hierarchical distribution of the address space with sub-prefixes allocated on a temporary basis to requesting organizations. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------------- "A framework for large-scale measurement platforms (LMAP)", Philip Eardley, Al Morton, Marcelo Bagnulo, Trevor Burbridge, Paul Aitken, Aamer Akhter, 2014-06-24, 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 platforms). "Large-Scale Broadband Measurement Use Cases", Marc Linsner, Philip Eardley, Trevor Burbridge, Frode Sorensen, 2014-04-02, Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the framework, information model and protocol. This document details two use cases that can assist to developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. "Information Model for Large-Scale Measurement Platforms (LMAP)", Trevor Burbridge, Philip Eardley, Marcelo Bagnulo, Jürgen Schönwälder, 2014-02-16, 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. Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keranen, 2014-02-13, 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. "A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks", Sandeep Kumar, Sye Keoh, Hannes Tschofenig, 2014-03-07, Transport Layer Security (TLS) is a widely used security protocol that offers communication security services at the transport layer. The initial design of TLS was focused on the protection of applications running on top of the Transmission Control Protocol (TCP), and was a good match for securing the Hypertext Transfer Protocol (HTTP). Subsequent standardization efforts lead to the publication of the Datagram Transport Layer Security (DTLS) protocol, which allows the re-use of the TLS security functionality and the payloads to be exchanged on top of the User Datagram Protocol (UDP). With the work on the Constrained Application Protocol (CoAP), as a specialized web transfer protocol for use with constrained nodes and constrained networks, DTLS is a preferred communication security protocol. Smart objects are constrained in various ways (e.g., CPU, memory, power consumption) and these limitations may impose restrictions on the protocol stack such a device runs. This document only looks at the security part of that protocol stacks and the ability to customize TLS/DTLS. To offer input for implementers and system architects this document illustrates the costs and benefits of various TLS/DTLS features for use with smart objects and constraint node networks. "Energy Efficient Implementation of IETF Constrained Protocol Suite", Zehn Cao, Carles Gomez, Matthias Kovatsch, Hui Tian, Xuan He, 2014-03-20, 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, Esko Dijk, Xuan He, Carsten Bormann, 2014-04-01, The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks, e.g., sensor nodes in a low-power lossy network (LLN). Yet to implement this Internet protocol on Class 1 devices (i.e., ~ 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 [I-D.ietf-core-coap], memory optimizations, and customized protocol parameters. Mobile Ad-hoc Networks (manet) ------------------------------ "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, 2014-03-23, 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 objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Cisco Cisco, Greg Harrison, Shawn Jury, Darryl Satterwhite, 2014-02-10, 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 forwarding 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. "Dynamic MANET On-demand (AODVv2) Routing", Charles Perkins, Stan Ratliff, John Dowdell, 2014-02-04, 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 on-demand convergence in dynamic topologies. "Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)", Christopher Dearlove, Thomas Clausen, 2014-06-25, 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. "Packet Sequence Number based directional airtime metric for OLSRv2", Henning Rogge, Emmanuel Baccelli, 2014-03-26, This document specifies an directional airtime link metric for usage in OLSRv2. "Snapshot of OLSRv2-Routed MANET Management", Thomas Clausen, Ulrich Herberg, 2014-04-14, 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 routing protocol OLSRv2 and its constituent protocol NHDP. Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single 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 can be sent to the Network Management System (NMS) via standardized management protocols. MBONE Deployment (mboned) ------------------------- "Automatic Multicast Tunneling", Gregory Bumgardner, 2014-04-24, This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. "Multicasting Applications Across Inter-Domain Peering Points", Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, ramki, 2014-03-03, This document examines the process of transporting applications via multicast across inter-domain peering points. The objective is to describe the setup process for multicast-based delivery across administrative domains and document supporting functionality to enable this process. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed Boucadair, Stig Venaas, Qiong, 2014-03-04, 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. "Multicast Geo-Distribution Control", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-02-06, Consider a content provider that wants to deliver a particular content to a set of customers/subscribers, where the provider and the subscribers are connected by an IP service provider. This document covers two areas needed to accomplish this: Multiple Interfaces (mif) ------------------------- "MIF API consideration", Dapeng Liu, Ted Lemon, Yuri Ismailov, Zhen Cao, 2014-02-14, Hosts may connect to the internet using more than one network API at a time, or to a single network on which service is provided by more than one provider. Existing APIs are inadequate to allow applications to successfully use the network in this environment. This document presents a new abstract API that provides the minimal set of messages required to enable an application to communicate successfully in this environment. "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 2014-06-23, 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. "Multiple Provisioning Domain Architecture", Dmitry Anipko, 2014-05-03, This document is a product of the work of MIF architecture design team. It outlines a solution framework for some of the issues, experienced by nodes that can be attached to multiple networks. The framework defines the notion of a Provisioning Domain (PVD) - a consistent set of network configuration information, and PVD-aware nodes - nodes which learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs for connectivity separately and consistently. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "IODEF Usage Guidance", Panos Kampanakis, 2014-05-01, The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It will also address how common security indicators can be represented in IODEF and use-cases of how IODEF is being used so far.The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. "The Incident Object Description Exchange Format v2", Roman Danyliw, Paul Stoecker, 2014-02-13, The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework 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. "IODEF Enumeration Reference Format", Adam Montville, David Black, 2014-06-20, The Incident Object Description Exchange Format (IODEF) provides a Reference class used to reference external entities (such as enumeration identifiers). However, the method of external entity identification has been left unstructured. This document describes a method to provide structure for referencing external entities for the IODEF Reference class and thus updates IODEF's ReferenceName (RFC5070). Mobility for IPv4 (mip4) ------------------------ "Flow Binding Support for Mobile IP", Sri Gundavelli, Kent Leung, George Tsirtsis, Hesham Soliman, Alex Petrescu, 2014-06-23, 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 flow policies for binding individual traffic 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-06-06, 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 signalling channel, defining the necessary RTSP extensions and procedures. "The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 2014-05-28, 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, 2014-03-17, 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)", Salvatore Loreto, Gonzalo Camarillo, 2014-02-13, SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2014-04-23, This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=" lines). This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264, in order to allow an answerer to in an SDP answer assign a non- zero port value to an "m=" line, even if the offerer in the associated SDP offer had assigned a zero port value to the "m=" line. "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", Emil Ivov, Hadriel Kaplan, Dan Wing, 2014-06-17, This document describes behavior of signaling intermediaries in Real- Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. Latching, which is one of the components of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of latching mechanism over the Internet and recommends other solutions such as the Interactive Connectivity Establishment (ICE) protocol. "WebRTC MediaStream Identification in the Session Description Protocol", Harald Alvestrand, 2014-06-09, 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 "m-line" 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, 2014-01-10, 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, 2014-01-15, 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, 2014-02-07, 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". "UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)", Christer Holmberg, Ivo Sedlacek, Gonzalo Salgueiro, 2014-06-20, This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar, 2014-02-14, 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. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. Multiprotocol Label Switching (mpls) ------------------------------------ "Updates to LDP for IPv6", Rajiv Asati, Vishwas Manral, Rajiv Papneja, Carlos Pignataro, 2014-02-05, The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. "Seamless MPLS Architecture", Nicolai Leymann, Bruno Decraene, Clarence Filsfils, Maciek Konstantynowicz, Dirk Steinberg, 2014-02-14, This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. "Inter-Area P2MP Segmented LSPs", Yakov Rekhter, Rahul Aggarwal, 2014-06-08, This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. "MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)", Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Tom Nadeau, 2014-05-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. "Controlling State Advertisements Of Non-negotiated LDP Applications", Kamran Raza, Sami Boutros, 2014-04-27, There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. "Definition of Time-to-Live TLV for LSP-Ping Mechanisms", Sami Boutros, Siva Sivabalan, George Swallow, Shaleen Saxena, Vishwas Manral, Sam Aldrin, 2014-03-24, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. "LDP Extensions for Multi Topology", Quintin Zhao, Kamran Raza, Chao Zhou, Luyuan Fang, Lianyuan Li, Daniel King, 2014-04-23, Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. "Temporal and hitless path segment monitoring", Alessandro D'Alessandro, Manuel Paul, Satoshi Ueno, Kaoru Arai, Yoshinori Koike, 2014-01-31, 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. 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. "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom Nadeau, 2014-06-15, 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) based Transport Profile (TP). "LDP Hello Cryptographic Authentication", Lianshu Zheng, Mach Chen, Manav Bhatia, 2014-06-19, This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. "Label Advertisement Discipline for LDP FECs", Kamran Raza, Sami Boutros, Luca Martini, Nicolai Leymann, 2014-04-02, The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, RFC 6388, and RFC 7140 by specifying the label advertisement mode for all currently defined LDP FEC types. "Encapsulating MPLS in UDP", Xiaohu Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, Fan Yongbing, 2014-01-24, This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP (User Datagram Protocol). Note that the MPLS-in-UDP encapsulation technology MUST only be deployed within a service provider network or networks of an adjacent set of co-operating service providers where the congestion control is not a concern. "MPLS Transport Profile Linear Protection MIB", Kingston Selvaraj, Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin, 2014-02-04, 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, 2014-04-02, In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the 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 Label Switching Router (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. "Requirements for MPLS-TP Shared Mesh Protection", Yaacov Weingarten, Sam Aldrin, Ping Pan, Jeong-dong Ryoo, Greg Mirsky, 2014-06-10, This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. "MPLS Forwarding Compliance and Performance Requirements", Curtis Villamizar, Kireeti Kompella, Shane Amante, Andy Malis, Carlos Pignataro, 2014-03-04, This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. "Proxy MPLS Echo Request", George Swallow, Vanson Lim, Sam Aldrin, 2014-01-02, This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. "mLDP Node Protection", IJsbrand Wijnands, Eric Rosen, Kamran Raza, Jeff Tantsura, Alia Atlas, Quintin Zhao, 2014-02-13, This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) built by LDP ("Label Distribution Protocol"), or simply 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 originated from the PLR LSR to the MPT LSRs while bypassing LSR node N. "Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification", Nobo Akiya, George Swallow, Carlos Pignataro, Loa Andersson, Mach Chen, 2014-05-20, 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 adds one value to the Reply Mode field to indicate reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC4379. "Extended Administrative Groups in MPLS-TE", Eric Osborne, 2014-05-29, MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. "Updates to MPLS Transport Profile Linear Protection", Eric Osborne, 2014-05-29, This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC6378. "Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs", Tarek Saad, Rakesh Gandhi, Zafar Ali, Robert Venator, Yuji Kamite, 2014-04-22, This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions for reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs) in an Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) networks. "Entropy labels for source routed stacked tunnels", Sriganesh Kini, Kireeti Kompella, Siva Sivabalan, 2014-02-14, 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 how ELs are to be applied to source routed stacked tunnels. "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Yakov Rekhter, Rahul Aggarwal, Nicolai Leymann, Wim Henderickx, Quintin Zhao, Renwei Li, 2014-03-03, When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using mLDP. "mLDP In-Band Signaling with Wildcards", IJsbrand Wijnands, Eric Rosen, arkadiy.gulko@thomsonreuters.com, Uwe Joorde, Jeff Tantsura, 2014-03-03, There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional Multicast" trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP "Any Source Multicast" trees is subject to certain applicability restrictions that are discussed in this document. "Extensions to RSVP-TE for LSP Egress Local Protection", Huaimo Chen, So Ning, Autumn Liu, Fengman Xu, Mehmet Toy, Lu Huang, Lei Liu, 2014-03-16, 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) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "Extensions to RSVP-TE for LSP Ingress Local Protection", Huaimo Chen, Raveendra Torvi, 2014-03-16, 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) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "MPLS Performance Measurement UDP Return Path", Stewart Bryant, Siva Sivabalan, Sagar Soni, 2014-05-21, 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. "Gap Analysis for Operating IPv6-only MPLS Networks", Wesley George, Carlos Pignataro, 2014-04-17, This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. "Deprecation of BGP Entropy Label Capability Attribute", John Scudder, Kireeti Kompella, 2014-06-18, RFC 6790 defines the BGP Entropy Label Capability attribute. Regrettably, it has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. "Deprecation of BGP Entropy Label Capability Attribute", John Scudder, Kireeti Kompella, 2014-06-23, RFC 6790 defines the BGP Entropy Label Capability attribute. Regrettably, it has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, 2014-01-23, 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. "Analysis of MPTCP residual threats and possible fixes", Marcelo Bagnulo, Christoph Paasch, Fernando Gont, Olivier Bonaventure, Costin Raiciu, 2014-06-23, This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them. Multicast Mobility (multimob) ----------------------------- "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Thomas Schmidt, Matthias Waehlisch, Rajeev Koodli, Gorry Fairhurst, Dapeng Liu, 2014-06-26, Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay- sensitive real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format. Network Configuration (netconf) ------------------------------- "Using the NETCONF Protocol over Transport Layer Security (TLS)", Mohamad Badra, Alan Luchuk, Jürgen Schönwälder, 2014-01-29, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This document obsoletes RFC 5539 and it adds an optional mechanism to establish the underlying TCP connection from the NETCONF server to the NETCONF client (call home). "NETCONF over SSH Call Home", Kent Watsen, 2014-04-18, This document presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH server, in order for the NETCONF client to open the IANA-assigned SSH subsystem "netconf". "RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen, Rex Fernando, 2014-03-23, This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. "YANG Patch Media Type", Andy Bierman, Martin Bjorklund, Kent Watsen, Rex Fernando, 2014-03-23, This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. "NETCONF Server Configuration Model", Kent Watsen, Jürgen Schönwälder, 2014-06-02, This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. Network-Based Mobility Extensions (netext) ------------------------------------------ "Logical Interface Support for multi-mode IP Hosts", Telemaco Melia, Sri Gundavelli, 2014-03-04, 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 operating in 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 context with various mobility management features. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 2014-06-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 on 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. "EAP Attributes for WiFi - EPC Integration", Ravi Valmikam, Rajeev Koodli, 2014-06-10, With WiFi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted WiFi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted WiFi access networks. "Separation of Control and User Plane for Proxy Mobile IPv6", Ryuji Wakikawa, Rajesh Pazhyannur, Sri Gundavelli, Charles Perkins, 2014-06-18, This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. "Mapping 802.11 QoS in a PMIPv6 Mobility Domain", John Kaippallimalil, Rajesh Pazhyannur, Parviz Yegani, 2014-05-07, This document provides a model for enabling end to end QoS in systems where there is a 802.11 based wireless system coupled with a PMIPv6 mobility domain consisting a local mobility anchor and mobility access gateway. This enables QoS policing and labeling of packets in a consistent manner on the 802.11 link between the MN and the AP as well as the link between the MAG and the LMA. To enable this, the document specifies mapping between QoS parameters on the 802.11 link and the QoS Mobility options in the PMIPv6 domain. NETCONF Data Modeling Language (netmod) --------------------------------------- "A YANG Data Model for Routing Management", Ladislav Lhotka, 2014-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 individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), routing protocols and route filters. "A YANG Data Model for System Management", Andy Bierman, Martin Bjorklund, 2014-05-14, This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. "A YANG Data Model for SNMP Configuration", Martin Bjorklund, Jürgen Schönwälder, 2014-05-19, This document defines a collection of YANG definitions for configuring SNMP engines. "JSON Encoding of Data Modeled with YANG", Ladislav Lhotka, 2014-04-22, This document defines rules for representing configuration and state data defined using YANG as JSON text. It does so by specifying a procedure for translating the subset of YANG-compatible XML documents to JSON text, and vice versa. A JSON encoding of XML attributes is also defined so as to allow for including metadata in JSON documents. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2014-06-16, 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. Network File System Version 4 (nfsv4) ------------------------------------- "NSDB Protocol for Federated Filesystems", James Lentini, Daniel Ellard, Renu Tewari, Chuck Lever, 2012-12-12, This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Administration Protocol for Federated Filesystems", James Lentini, Daniel Ellard, Renu Tewari, Chuck Lever, 2012-12-12, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Network File System (NFS) Version 4 Protocol", Tom Haynes, David Noveck, 2014-04-11, The Network File System (NFS) version 4 is a distributed file system protocol which builds on the heritage of NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", Tom Haynes, David Noveck, 2014-04-11, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes its heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access, while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. RFC3530bis formally obsoleting RFC 3530. This document, together with RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. "NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description", Tom Haynes, 2014-05-19, This Internet-Draft provides the XDR description for NFSv4 minor version two. "NFS Version 4 Minor Version 2", Tom Haynes, 2014-05-19, This Internet-Draft describes NFS version 4 minor version two, focusing mainly on the protocol extensions made from NFS version 4 minor version 0 and 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, 2014-02-14, This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides for compound authentication of client hosts and users to server (constructed by generic composition), security label assertions for multi-level and type enforcement, structured privilege assertions, and channel bindings. "Object-Based Parallel NFS (pNFS) Operations", Benny Halevy, Boaz Harrosh, Brent Welch, Brian Mueller, 2014-05-03, Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) 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, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. This document has been updated since the initial version to clarify and fix some of the RAID-related computations so they match current implementations. "NFSv4 migration: Implementation experience and spec issues to resolve", David Noveck, Piyush Shivam, Chuck Lever, Bill Baker, 2014-03-15, 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, 2014-03-30, 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 the NFSv4.0 specification (RFC3530 and possible successors) to address these problems. "Registry Specification for Mandatory Access Control (MAC) Security Label Formats", David Quigley, Jarrett Lu, Tom Haynes, 2014-05-02, In the past Mandatory Access Control (MAC) systems have used very rigid policies which were hardcoded into the particular protocol and platform. As MAC systems are more widely deployed additional flexibility in mechanism and policy is required. Where traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include technologies such as type enforcement. Due to the wide range of policies and mechanisms it has proven through past efforts to be virtually impossible to accomodate all parties in one security label format and model. To allow multiple MAC mechanisms and label formats in a network, this document proposes a registry of label format specifications. This registry contains several identifiers to accomodate both integer and string preferences and associates those identifiers with an extensive document outlining the exact syntax and use of the particular label format. Network Management Research Group (nmrg) ---------------------------------------- "Gap Analysis for Autonomic Networking", Michael Behringer, Brian Carpenter, Sheng Jiang, 2014-04-09, This document summarises a problem statement for an IP-based autonomic network that is mainly based on distributed network devices. The document reviews the history and current status of autonomic aspects of IP networks. It then reviews the current network management style, which is still heavily depending on human administrators. Finally the document describes the general gaps between the ideal autonomic network concept and the current network abilities. "Autonomic Networking Use Case for Distributed Detection of SLA Violations", Jeff, Alex Clemm, Alberto Prieto, Lisandro Granville, 2014-06-23, This document describes a use case for autonomic networking in distributed detection of SLA violations. It is one of a series of use cases intended to illustrate requirements for autonomic networking. Individual Submissions (none) ----------------------------- "Use of SRV records in conjuction with HTTP and URIs"", Mark Andrews, Thor Kottelin, 2014-05-19, The combined use of SRV records for HTTP along with URIs is not as straight forward as it would appear at first glance. This document looks at the issues involved and recommends solutions. "An IPv4 Flowlabel Option", Thomas Dreibholz, 2014-01-04, 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, 2014-01-10, 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). "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 2014-01-04, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "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. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 2014-01-15, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 2014-01-04, 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, 2014-01-04, 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. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 2014-04-22, One goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. A second goal is to reduce retransmissions and failures when AS2 is used in a synchronous mode for transmitting MDNs. There can be a large latency between receipt of the POSTed entity body and the MDN response caused by the operations of decompressing, decrypting, and signature checks. Uncoordinated timeout policies and intermediate devices dropping connections have interfered with reliable data exchange. The use of an HTTP 102(Processing) status code is described to mitigate these difficulties. Use of these reliability features is indicated by presence of the "AS2-Reliability" value in the EDIINT-Features header. Intended Status The intent of this document is to be placed on the RFC track as an Informational RFC. Feedback Instructions: NOTE TO RFC EDITOR: This section should be removed by the RFC editor prior to publication. If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS2 Reliability" in the Subject field. To enter or follow the discussion, you need to subscribe to ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. "The Public Suffix Structure file format and its use for Cookie domain validation", Yngve Pettersen, 2014-02-13, This document defines the term "Public Suffix domain" as meaning a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains. Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". It also defines a file format that can be used to distribute information about such Public Suffix domains to relying parties. As an example, this information is then used to limit which domains an Internet service can set HTTP cookies for, strengthening the rules already defined by the cookie specification. This specification updates RFC 6265 [RFC6265] by defining the term "Public Suffix domain". "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2014-01-04, 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, 2014-01-04, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Calendar Availability", Cyrus Daboo, Mike Douglass, 2014-01-30, 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. "Using Saratoga with a Bundle Agent as a Convergence Layer for Delay- Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 2014-04-19, Saratoga is a simple, lightweight, UDP-based transfer protocol. This describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the Bundle Protocol and its Bundle Agents, building on the Saratoga specification in draft-wood-tsvwg-saratoga. "Handle Resolution Option for ASAP", Thomas Dreibholz, 2014-01-04, 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, 2014-01-04, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Carlo Kopp, Mike Tyson, 2007-12-21, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 2014-04-19, 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 for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, 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. "Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 2014-06-02, This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks, by making every transit node in the network HTTP-capable, and doing peer HTTP transfers between nodes to move data hop-by-hop or subnet-by-subnet towards its final destination. HTTP is well- known and straightforward to implement in these networks. "The BagIt File Packaging Format (V0.97)", Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas, 2014-01-28, 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, PENG JIANG, 2014-04-15, 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. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 2010-01-15, This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "BGP Extended Community for QoS Marking", Thomas Knoll, 2014-01-10, 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, 2014-05-11, 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, 2014-02-13, 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. "EDNS EXPIRE OPTION", Mark Andrews, 2014-03-27, This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries. "Extreme Networks' Ethernet Automatic Protection Switching (EAPS), Version 1.3", Arnel Lim, Steven Blake, Sunil Shah, 2011-07-05, This document describes version 1.3 of the Ethernet Automatic Protection Switching (EAPS) (TM) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at lower cost and without some of the constraints (e.g. ring size) of SONET. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 2014-01-04, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "HTTP Live Streaming", Roger Pantos, 2014-04-16, 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 6 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. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 2014-01-03, This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL). SEAL operates over virtual topologies configured over connected IP network routing regions bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, where they may incur packet duplication, packet reordering, source address spoofing and traversal of links with diverse Maximum Transmission Units (MTUs). SEAL addresses these issues through the encapsulation and messaging mechanisms specified in this document. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2014-01-27, 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. "dIVI: Dual-Stateless IPv4/IPv6 Translation", Congxiao Bao, Xing Li, Yu Zhai, Wentao Shang, 2014-01-03, This document presents the concepts and the implementations of address-sharing dual-stateless IPv4/IPv6 translation (dIVI). The dIVI is an extension of 1:1 stateless IPv4/IPv6 translation with features of IPv4 address sharing and dual translation. The major benefits of those extensions are using public IPv4 addresses more effectively and removing the requirements of DNS64 and ALG, without loosing the stateless, end-to-end address transparency and bidirectional-initiated communications. "DNS46 for the IPv4/IPv6 Stateless Translator", Congxiao Bao, Xing Li, 2014-01-06, The stateless translator can support IPv6-initiated communications as well as IPv4-initiated communications for IPv6 hosts using IPv4- translatable addresses. DNS support for the IPv6-initiated communication is defined in the DNS64 specification. This document defines the DNS46 function for the stateless translator. "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. "AS2 Restart for Very Large Messages", Terry Harding, 2014-06-16, AS2 Restart provides a method for AS2 clients and servers to restart payload transfers from the point of failure without requiring the entire document to be resent. Keywords "Mesh Structured Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 2014-03-04, 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. "rxgk: GSSAPI based security class for RX", Simon Wilkinson, Benjamin Kaduk, 2014-03-02, rxgk is a security class for the RX RPC protocol. It uses the GSSAPI framework to provide an authentication service that provides authentication, confidentiality and integrity protection for the rxgk security class. This document provides a general description of rxgk and how to integrate it into generic RX applications. Application specific behaviour will be described, as necessary, in future documents. "Integrating rxgk with AFS", Simon Wilkinson, Benjamin Kaduk, 2014-04-10, 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, 2014-01-07, 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, 2014-01-07, 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. "New Properties for iCalendar", Cyrus Daboo, 2014-03-16, 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. "HIP-based Virtual Private LAN Service (HIPLS)", Tom Henderson, Steven Venema, David Mattes, 2013-12-26, The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment. "Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address", Alper Yegin, Yoshihiro Ohba, Lionel Morand, John Kaippallimalil, 2012-02-14, This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address. "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. "Pre-standard Linear Protection Switching in MPLS-TP", Huub van Helvoort, Jeong-dong Ryoo, Zhang Haiyan, Feng Huang, Han Li, Alessandro D'Alessandro, 2014-03-03, The IETF Standards Track solution for MPLS Transport Profile (MPLS- TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- updates and draft-ietf-mpls-tp-psc-itu. This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication these pre-standard implementations were still in operation carrying live traffic. The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by MPLS-TP data plane, and can work without any control plane. [Editor's note] The followings are to be included in "Status of Memo": This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc- editor.org/info/rfcxxxx. "Advanced Groupware Access Protocol", Iulian Radu, 2014-05-01, 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. "Protocol for Stage Illumination", Marcus Ertl, 2014-05-28, This memo describes a protocol that builds upon UDP/IP to transport illumination and control data for stage, architectural and other illumination requirements. It may be understood as a spiritual successor of the traditional DMX (Digital MultipleX) specification series, removing it's limitations and adding flexibility and usability enhancements like auto-discovery and metadata, among other useful features. Due to the complexity and length, versions 4 and above only describe a subset of the full PSI. "A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control", Charles Shen, Henning Schulzrinne, Arata Koike, 2014-02-10, When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Restart-Timer header in normal response messages. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Restart-Timer header value before sending out the first request attempt. Thus, the mechanism spreads all the initial client requests and prevents them from overloading the server. "Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources", Mo McRoberts, Alexander Adolf, 2013-03-26, Uniform Resource Identifier (URI) schemes for broadcasting programme resources transmitted over MPEG-2 Transport Streams [MPEG-Systems] have been devised in their process of creating standards by the Digital Video Broadcasting Project (DVB), the Association of Radio Industries and Businesses in Japan (ARIB) and the OpenCable Application Platform (OCAP) to acquire current and future scheduled publications of broadcast media content from multimedia applications such as HTTP, MHP [DVB-MHP], OCAP [OCAP1.0] or other XML based metadata. These URI are used to locate the actual digital TV, Radio or other multimedia broadcast programme services (i.e., channels or events) and also the audio-visual components related to that programme, for example an HTTP-based programme guide on the Web or other XML-based electronic programme guides in digital broadcast receivers. This document defines the "dvb" URI scheme for the benefit of the Internet community, given its definition as part of the Digital Video Broadcasting (DVB) suite of ETSI standards. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana, Preethi Natarajan, Randall Stewart, Michael Tuexen, 2014-03-19, 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. "ISIS Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 2014-03-20, The Path Computation Element (PCE) may be used for computing multi- domain (Area or AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switch Path (LSP). In this circumstance, it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information in a simple way. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of Boundary Node (BN)Discovery information within an IS-IS area or within the entire IS-IS routing domain. "OSPF Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 2014-03-20, The Path Computation Element (PCE) may be used for computing multi- domain (Area or AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switch Path (LSP). In this circumstance, it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information in a simple way. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of Boundary Node (BN) Discovery information within an OSPF area or within the entire OSPF routing domain. "Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen, 2014-02-13, 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. "EDNS Option Code for SIP and PSTN Source Reference Info", Hadriel Kaplan, Robert Walter, Pierce Gorman, Manjul Maharishi, 2011-10-24, This document requests an IANA allocation for an EDNS0 Option-Code, per [RFC2671], for a UTF-8 encoded string field containing a URI for private use. The intended use of this field is for providing SIP and PSTN-type source information for ENUM-resolution DNS queries, in private DNS server environments such as Private ENUM. "Timezone Service Protocol", Mike Douglass, Cyrus Daboo, 2014-03-15, This document defines a timezone service protocol that allows reliable, secure and fast delivery of timezone data to client systems such as calendaring and scheduling applications or operating systems. "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. "Registry Specification for Mandatory Access Control(MAC) Security Label Formats", David Quigley, Jarrett Lu, Tom Haynes, 2014-04-17, In the past Mandatory Access Control (MAC) systems have used very rigid policies which were hardcoded into the particular protocol and platform. As MAC systems are more widely deployed additional flexibility in mechanism and policy is required. Where traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include technologies such as type enforcement. Due to the wide range of policies and mechanisms it has proven through past efforts to be virtually impossible to accomodate all parties in one security label format and model. To allow multiple MAC mechanisms and label formats in a network, this document proposes a registry of label format specifications. This registry contains several identifiers to accomodate both integer and string preferences and associates those identifiers with an extensive document outlining the exact syntax and use of the particular label format. "Port Management To Reduce Logging In Large-Scale NATs", Tina Tsou, Weibo Li, Tom Taylor, Jing Huang, 2013-07-02, 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. "Media Resource Broker (MRB) Location Function (MLF)", Chris Boulton, John Dally, 2014-01-27, The MediaCtrl work group in the IETF has produced a complete architecture for controlling media server resources in Internet Protocol (IP) based networks. An important function in the MediaCtrl architecture is the Media Resource Broker entity which monitors and allocates media resources to requesting applications. This document introduces a Media Resource Broker (MRB) Location Function (MLF) which works in partnership with MRB's in large deployments providing a light weight scaling and failover mechanism. "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. "Default Port for IRC via TLS/SSL", Richard Hartmann, 2014-01-23, This document describes the commonly accepted practice of listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. "DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob Schlyter, Guy Bailey, 2014-06-03, 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. "Management Information Base (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation.", Dhruv Dhody, Udayasree Palle, Quintin Zhao, Daniel King, 2014-02-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs when path-key-based confidentiality in inter-domain path computation is requested. "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", Ira McDonald, Michael Sweet, 2014-04-20, This memo defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. This memo is an individual submission to the IETF by the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software. This memo defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this memo does not update or obsolete (RFC 3510). This memo updates RFC 2910 and RFC 2911. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology with IPv4 Address Sharing", Naoki Matsuhira, 2014-01-07, 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. "MAC Address Withdrawal over Static Pseudowire", Siva Sivabalan, Sami Boutros, Himanshu Shah, Sam Aldrin, 2014-02-10, 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. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 2014-01-04, 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, 2014-01-04, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "Fault Detection and Recovery in Wireless Sensors Network", Humayun Bakht, 2014-01-13, Wireless Sensors networks (WSNs) are type of wireless ad-hoc networks with reduced or no mobility. These networks combine wireless communication with minimal onboard computation facilities for sensing and monitoring of physical and environmental phenomena. Much work has been reported on different aspects of wireless sensors networks;however,less attention has been paid on addressing fault detection and recovery in these networks. Fault could be any thing which can lead communication break down as a whole or part of a wireless sensors network.Thus, detection of such fault attains a primary focus to support routine operations within such networks. Mobile Ad-hoc On Demand Data Delivery Protocol (MAODDP) belongs to on-demand data delivery type routing family of mobile ad-hoc networks. The contribution of this paper is to introduce an efficient fault detection and recovery mechanism for WSNs network. We believe proposed two step model can offer a robust solution for the fault management in Wireless Sensors Network. "Commentary on the Design of the Authenticated-Enveloped-Data Content Type", Jim Schaad, 2011-04-06, The Authenticated-Enveloped-Data Content Type allows for the use of Authenticated-Enveloped modes with block cipher algorithms. At the time of the original design there was discussion about the relative location of the authenticated attributes and the encrypted content in the ASN.1 structure. With the benefits of implementation experience I revisit the discussion made at the time and re-evaluate the decision made. "Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai Yang, Jianping Wu, Jun Bi, 2014-06-12, 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, So Ning, Paul Unbehagen, Monique Morrow, Masum Hasan, Yuri Demchenko, Meng Yu, 2014-01-03, 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. "ECN for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Michael Tuexen, Xuesong Dong, 2014-01-15, This document describes the addition of the ECN to the Stream Control Transmission Protocol (SCTP). "A Session Initiation Protocol (SIP) INFO package for Private Wire", Richard Beauchamp, Finlay Fraser, Chris Boulton, 2014-01-27, Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data. "A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)", Roozbeh Atarius, 2014-06-16, This document allows a Mobile Equipment Identity (MEID) to be used as a Uniform Resource Name (URN) by registering a URN namespace for MEIDs. The structure of an MEID is 15 hexadecimal encoded digits long and is defined in 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The Third Generation Partnership Project 2 (3GPP2) has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. "Event Publishing Extensions to iCalendar", Mike Douglass, 2014-02-01, This specification introduces a number of new iCalendar properties which are of particular use for event publishers and in social networking. "Multipath RTP (MPRTP)", Varun Singh, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 2014-01-13, 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. "MPLS-TP Ring Protection Switching (MRPS)", Huub van Helvoort, Jeong-dong Ryoo, 2014-04-17, This document describes a mechanism to address the requirements for protection of the Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) in a ring topology. The mechanism defined herein is designed to support point-to-point as well as point-to-multipoint LSPs. The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes using the mechanisms defined in the [RFC6371]. The Automatic Protection Switching (APS) protocol is used for coordination of protection switching actions between the ring nodes. "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Bob Briscoe, John Kaippallimalil, Patricia Thaler, 2014-03-04, 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. "Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)", Fatai Zhang, Oscar de Dios, Adrian Farrel, Xian Zhang, Daniele Ceccarelli, 2014-02-13, Generalized Multiprotocol Label Switching (GMPLS) defines a set of protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. The GMPLS User-Network Interface (UNI) was developed in RFC4208 in order to be applied to an overlay network architectural model. This document examines a number of GMPLS UNI application scenarios. It shows how techniques developed after the GMPLS UNI can be applied to automate or enable critical processes for these applications. This document also suggests simple extensions that could be made to existing technologies to further enable the UNI and points out some unresolved issues. "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Radia Perlman, Donald Eastlake, Anoop Ghanwani, ZTE Corporation, 2014-01-02, Extending TRILL to multiple levels has one challenge that is not addressed by the already-existing capability of IS-IS to have multiple levels. The issue is with RBridge nicknames. There have been two proposed approaches. One approach, which we refer to as the "unique nickname" approach, gives unique nicknames to all the RBridges in the multilevel campus, either by having the level-1/level-2 border RBridges 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 assigning nicknames to the areas, and allowing nicknames to be reused in different areas, by having the border RBridges rewrite the nickname fields when entering or leaving an area. Each of those approaches has advantages and disadvantages. The design in this document allows a choice of approach in each area, allowing the simplicity of the unique nickname approach in installations in which there is no danger of running out of nicknames, and allowing nickname rewriting to be phased into larger installations on a per-area basis. "A packet based method for passive performance monitoring", Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Alberto Bonda, 2014-02-13, 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 has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, 2014-04-06, 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. "Reusing the IPv4 Identification Field in Atomic Packets", Bob Briscoe, 2014-02-14, This specification takes a new approach to extensibility that is both principled and a hack. It builds on recent moves to formalise the increasingly common practice where fragmentation in IPv4 more closely matches that of IPv6. The large majority of IPv4 packets are now 'atomic', meaning indivisible. In such packets, the 16 bits of the IPv4 Identification (IPv4 ID) field are redundant and could be freed up for the Internet community to put to other uses, at least within the constraints imposed by their original use for reassembly. This specification defines the process for redefining the semantics of these bits. It uses the previously reserved control flag in the IPv4 header to indicate that these 16 bits have new semantics. Great care is taken throughout to ease incremental deployment, even in the presence of middleboxes that incorrectly discard or normalise packets that have the reserved control flag set. "Changing DNS Operators for DNSSEC signed Zones", Peter Koch, Marcos Sanz, Antoin Verschuren, 2014-02-14, Changing the DNS delegation for a DNS zone is quite involved if done by the books, but most often handled pragmatically in today's operational practice at the top level with registries and registrars. This document describes a delegation change procedure that maintains consistency and validation under DNSSEC. "Data Center Mobility based on E-VPN, BGP/MPLS IP VPN, IP Routing and NHRP", Rahul Aggarwal, Yakov Rekhter, Wim Henderickx, Ravi Shekhar, Luyuan Fang, Ali Sajassi, 2014-06-02, This document describes a set of network-based solutions for seamless Virtual Machine mobility in the data center. These solutions provide a toolkit which is based on IP routing, E-VPNs, BGP/MPLS IP VPNs, and NHRP. "A LoST extension to support return of complete and similar location info", Roger Marshall, Jeff Martin, Brian Rosen, 2014-02-14, This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether a valid or invalid location is returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic location element set for a valid response, and one or more suggested sets of civic location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete" or "similar" locations, and are included as compilation of ca type xml elements within the existing response message structure. "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 SAVI solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin, 2014-02-06, This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP to bind IP address with 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 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. "Suite B Profile for Datagram Transport Layer Security / Secure Real-time Transport Protocol (DTLS-SRTP)", Michael Peck, Kevin Igoe, 2013-12-26, The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document describes the use of Suite B cryptography with the Datagram Transport Layer Security (DTLS) protocol, the Secure Real-Time Transport Protocol (SRTP), and the Secure Real-Time Transport Control Protocol (SRTCP) to provide a robust architecture for securing real-time data. "Standardised ECC Cipher Suites for TLS", Peter Gutmann, 2014-06-10, This document describes a set of standard ECC cipher suites for TLS that simplify the complex selection procedure described in the existing ECC RFC, simplifying implementation and easing interoperability problems. "A Taxonomy on Private Use Fields in Protocols", Chris Lonvick, 2014-06-09, This document attempts to provide some clarification for the way that private use fields have been used in protocols developed in the IETF. It is strictly a taxonomy of what has been published and offers a minimal amount of advice about how to design or use private use options. "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, 2014-03-31, 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). [RFC6006] and [PCE-P2MP-PROCEDURES] 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). "IPv6 Support Within IETF work", Wesley George, Lee Howard, 2014-01-06, This document recommends that IETF formally require its standards work to be IP version agnostic or to explicitly include support for IPv6, with some exceptions. It further recommends that IETF revisit and update the previous attempts to review existing standards for IPv6 compliance. It makes this recommendation in order to ensure that it is possible to operate without dependencies on IPv4. "User-Managed Access (UMA) Profile of OAuth 2.0", Thomas Hardjono, 2014-03-06, 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.Met at advisory in Feb 2014. "BGPSEC Design Choices and Summary of Supporting Discussions", Kotikalapudi Sriram, 2014-01-07, 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. "RBridge: Pseudo-Nickname for Active-active Access", ZTE Corporation, Tissa Senevirathne, Radia Perlman, Donald Eastlake, Mingui Zhang, Li Yizhou, 2014-06-24, 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. In this document, the edge RBridge (TRILL switch) group providing active-active access to such an end station can be represented as a Virtual RBridge. Based on the concept of Virtual RBridge along with its pseudo-nickname, this document facilitates the TRILL active-active access of such end stations. "Mediated RSA cryptography specification for additive private key splitting (mRSAA)", Miroslaw Kutylowski, Przemyslaw Kubiak, Michal Tabor, Daniel Wachnik, 2012-11-05, This document describes recommendations for the implementation of public key cryptography based on the mediated RSA algorithm. The Mediated RSA algorithm bases on fragmentation of a private key. As a result the signature process consists from multiple stages. The verification process is the same as in the case of RSA algorithm [RFC3447]. "The Interior Routing Overlay Network (IRON)", Fred Templin, 2014-03-28, Since large-scale Internetworks such as the public Internet must continue to support escalating growth due to increasing demand, it is clear that Autonomous Systems (ASes) must avoid injecting excessive de-aggregated prefixes into the interdomain routing system and instead mitigate de-aggregation internally. This document describes an Interior Routing Overlay Network (IRON) architecture that supports sustainable growth within AS-interior routing domains while requiring no changes to end systems and no changes to the exterior routing system. In addition to routing scaling, IRON further addresses other important issues including mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Mallik Mahalingam, Dinesh Dutt, Kenneth Duda, Puneet Agarwal, Lawrence Kreeger, T. Sridhar, Mike Bursell, Chris Wright, 2014-04-10, This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in cloud service provider and enterprise data center networks. This memo documents the deployed VXLAN protocol for the benefit of the IETF community. "NVGRE: Network Virtualization using Generic Routing Encapsulation", Murari Sridharan, Albert Greenberg, Yu-Shun Wang, Pankaj Garg, Narasimhan Venkataramiah, Kenneth Duda, Ilango Ganga, Geng Lin, Mark Pearson, Patricia Thaler, Chait Tumuluri, 2014-02-04, 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, 2014-04-19, 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. "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, Olivier Vautrin, 2014-01-13, In some instances, Service Providers have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g. for abuse response). Unfortunately, many Carrier Grade NAT logging solutions require active logging of dynamic translations. Carrier Grade NAT port assignments are often per-connection, but could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. While the authors acknowledge that IPv6 is a preferred solution, Carrier Grade NAT is a reality in many networks, and is needed in situations where either customer equipment or Internet content only supports IPv4; this approach should in no way slow the deployment of IPv6. "Congestion control for the Saratoga protocol", Lloyd Wood, Wesley Eddy, Will Ivancic, 2014-04-19, 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. "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", Pat Fleming, Ira McDonald, 2014-03-13, This document defines a schema, object classes and attributes, for Printers and Print Services, for use with directories that support Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (RFC 2911). Additional Printer attributes are based on definitions in the Printer MIB v2 (RFC 3805), IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). This document is an individual submission to the IETF by the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software. This document obsoletes RFC 3712. "IANA Allocated DNS RRtype Codes Without Documentation", Edward Lewis, 2011-10-13, In the IANA registry of Resource Record (RR) TYPEs, as of October 1, 2011, there are 10 type code values allocated with references that are individual email boxes and not stable documents. Some of the registrations represent works in progress and such a reference is viable. Some registrations are dormant or dead efforts. In all cases it would be helpful to have some reference to material describing the type. "Securing Header Fields with S/MIME", Laurent Cailleux, Chris Bonatti, 2014-04-09, This document describes how the S/MIME protocol can be extended in order to secure message header fields. This technology provides security services such as data integrity, non-repudiation and confidentiality. This extension is referred to as 'Secure Headers'. "Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing Li, 2014-01-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. "Directory Assisted TRILL Encapsulation", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, 2014-04-08, This draft describes how data center network can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from directory service. "OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, Alvaro Retana, So Ning, Mehmet Toy, Lei Liu, 2014-01-15, 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. "Cross Stratum Optimization Architecture for Optical as a Service", Hui Yang, Yongli Zhao, Jie Zhang, Young Lee, Yi Lin, Fatai Zhang, 2014-06-02, 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. "IP VPN Scaling Considerations", Wesley George, Rob Shakir, 2014-02-14, This document discusses scaling considerations unique to implementation of Layer 3 (IP) Virtual Private Networks, discusses a few best practices, and identifies gaps in the current tools and techniques which are making it more difficult for operators to cost- effectively scale and manage their L3VPN deployments. "SM3 Hash function", Sean Shen, Sean Shen, 2014-02-14, This document discribles a hash function which is invented by Xiaoyun Wang et al. This algorithm is published by Chinese Commercial Cryptography Administration Office ([SM3]) for the use of electronic authentication service system. This document gives IETF standard description of the algorithm. "A framework for RPs to use IKEv2 KMP", Uma Chunduri, Albert Tian, Joseph Touch, 2014-02-04, This document describes a mechanism to enable using IKEv2 with TCP- AO, which may also be of more general use to other pairwise Routing Protocols. "SM2 Digital Signature Algorithm", Sean Shen, Sean Shen, XiaoDong Lee, 2014-02-14, This document discribles a set of public key cryptographic algorithms based on elliptic curves which is invented by Xiaoyun Wang et al. These algorithms and recommended parameters are published by Chinese Commercial Cryptography Administration Office ([SM2 Algorithms] and [SM2 Algorithms Parameters]) for the use of electronic authentication service system. This document gives IETF standard description of the algorithms and parameters in [SM2 Algorithms] and [SM2 Algorithms Parameters]. The document [SM2 Algorithms] published by Chinese Commercial Cryptography Administration Office includes four parts: general introdocution, Digital Signature Algorithm, Key Exchange Protocol and Public Key Encryption Algorithm. The document [SM2 Algorithms Parameters] gives a set of recommended parameters. "CalDAV Managed Attachments", Cyrus Daboo, Arnaud Quillaud, 2014-02-05, This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data, to be stored and managed on the server. "TRILL IS-IS MTU Negotiation", Mingui Zhang, Xudong Zhang, Donald Eastlake, Radia Perlman, Vishwas Manral, Somnath Chatterjee, 2014-02-13, The base IETF TRILL protocol has a TRILL campus wide MTU feature, specified in RFC 6325 and RFC6327bis, 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 6325. "A General Framework of Source Address Validation and Traceback for IPv4/IPv6 Transition Scenarios", Hui Deng, Guangwu Hu, Jun Bi, Mingwei Xu, Fan Shi, 2014-05-04, 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, Hui Deng, Liang Zhu, Guangwu Hu, 2014-05-03, 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. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 2014-03-03, This document describes characteristics of communication between nodes 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. "Multicast Geo-Distribution Control", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 2014-02-05, Consider a content provider that wants to deliver a particular content to a set of customers/subscribers, where the provider and the subscribers are connected by an IP service provider. This document covers two areas needed to accomplish this: "Plasma Service Trust Processing", Jim Schaad, 2014-02-14, RFC TBD describes a new model and set of requirements to implement a labeling system on Cryptographic Message Syntax (CMS) objects where the entity in charge of doing the label enforcement is under the control of a central authority rather than the recipient of the object. This document describes a protocol to be used by senders and recipients of CMS objects to communicate with a centralized label enforcement server. The document outlines how a client will get the set of labels or policies that it can use for sending messages, composes a secure CMS object with a label on it and gets the necessary keys to decrypt a CMS object from the server. This document is designed to be used with RFC TBD2 which describes the extensions used in CMS objects to hold the label information. "Miscellaneous CoAP Group Communication Topics", Esko Dijk, Akbar Rahman, 2014-06-09, This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol (CoAP). The intent of this document is to keep track of useful ideas while the main CoRE WG Group Communication draft goes through the RFC publication process. These ideas may be then be used as input to future standardization in the CoRE or other related WGs. "A PMIPv6-based solution for Distributed Mobility Management", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, 2014-02-03, 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 (UUAS)", Mateusz Karcz, 2012-01-27, User-Agent is a header used by certain protocols, e.g. HTTP. Unified User-Agent String is intended to unification of that complicated strings. "Text Encodings of PKIX and CMS Structures", Simon Josefsson, Sean Leonard, 2014-04-30, This document describes and discuss the text encodings of Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate Revocation Lists (CRLs), PKCS #10 Certification Request Syntax, PKCS #7 structures, Cryptographic Message Syntax (CMS), PKCS #8 Private- Key Information Syntax, and Attribute Certificates. The text encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability going forward. "Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu, 2014-05-19, 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. "Observations of RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi, 2014-05-06, With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - having been published as a Proposed Standard after a ~2-year development cycle, this document presents an evaluation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations of the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these. "Reporting Unobserved Fields in IPFIX", Paul Aitken, 2013-12-31, The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. "Definitions of Managed Objects for 4rd", Yu Fu, Sheng Jiang, Bing Liu, 2014-02-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 managed objects for 4rd. "Distributed Mobility Anchoring", Pierrick Seite, Philippe Bertin, Jong-Hyouk Lee, 2014-02-06, Most existing IP mobility solutions are derived from Mobile IP principles where a given mobility anchor maintains Mobile Nodes (MNs) binding up-to-date. Data traffic is then encapsulated between the mobility anchor and the MN or its Access Router. These approaches are usually implemented on a centralised architectures where both MN context and traffic encapsulation need to be processed at a central network entity, i.e. the mobility anchor. However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of legay Proxy Mobile IP approach in such a flat architecture. The solution allows to dynamically distribute mobility functions among access routers for an optimal routing management. The goal is also to dynamically adapt the mobility support of the MN's needs by applying traffic redirection only to MNs' flows when an IP handover occurs. "Cross Stratum Optimization enabled Path Computation", Dhruv Dhody, Young Lee, Luis Contreras, Oscar de Dios, Nicola Ciulli, 2014-01-19, 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 Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model", Jose Saldana, Dan Wing, Julian Navajas, Muthu Perumal, Fernando Blanco, 2014-06-10, Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a method for improving the bandwidth utilization of network segments that carry multiple flows in parallel sharing a common path. The method combines standard 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-TF 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. "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", Bruce Davie, Jesse Gross, 2014-04-15, Network Virtualization places unique requirements on tunneling protocols. This draft describes STT (Stateless Transport Tunneling), a tunnel encapsulation that enables overlay networks to be built in virtualized networks. STT is particularly useful when some tunnel endpoints are in end-systems, as it utilizes the capabilities of the network interface card to improve performance. "Representing Label Generation Rulesets using XML", Kim Davies, Asmus Freytag, 2014-03-26, 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 particularly used for the implementation of Internationalized Domain Names (IDNs). 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. "LDP Extensions for Lock Instruct and Loopback of Pseudowire in MPLS Transport Profile", Jie Dong, Mach Chen, Greg Mirsky, 2014-04-21, This document specifies extensions to the Label Distribution Protocol (LDP) to support the provisioning of lock instruct (LI) and loopback (LB) mechanisms for MPLS Transport Profile (MPLS-TP) pseudowires (PWs). "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. "IANA Registry for RTCWeb Constrainable Properties", Daniel Burnett, 2014-02-14, 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. "PMIPv6-based Distributed Mobility Management", Jaehwoon Lee, Young-Han Kim, 2014-05-20, 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 letter proposes the 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. Therefore, the performance is not degraded due to the overhead to query the location of the MN. "Scaling the Address Resolution Protocol for Large Data Centers (SARP)", Youval Nachum, Linda Dunbar, Ilan Yerushalmi, Tal Mizrahi, 2014-01-12, This document introduces SARP, an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' FDB (MAC table) sizes and ARP/ND impact on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of VMs that can move across various physical locations. "PMIPv6-based distributed anchoring", Carlos Bernardos, Juan-Carlos Zúñiga, 2014-05-15, 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, 2014-05-06, The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some 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. "MAC Address Withdrawal over Static Pseudowire", Siva Sivabalan, Sami Boutros, Himanshu Shah, Sam Aldrin, Mannan Venkatesan, 2014-04-02, 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. "Path Computation Element (PCE) Database Requirements", Olivier Dugeon, Julien Meuric, Richard Douville, Ramon Casellas, Oscar de Dios, 2014-02-14, The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation. In a fist approach, the PCE embeds a Traffic Engineering Database (TED) containing all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure or PCE Hierarchy) or WG draft (like draft-ietf-pce-stateful-pce ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identify some Database, at large, requirements for the PCE. It is split in two main sections: the identification of the specific information to be stored in the PCE Database and how it may be populated. "Requirements for Message Access Control", Trevor Freeman, Jim Schaad, Patrick Patterson, 2014-05-19, 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 standard and is in not intended to be a one off just for email and can also be applied 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, 2014-03-13, 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. "SPB Deployment Considerations", Roger Lapuh, Paul Unbehagen, Peter Ashwood-Smith, Phillip Taylor, 2014-03-31, Based on many live deployments, including the Sochi Winter Olympics 2014 network and multiple interoperability events, this document provides advice to network operators about best practices when implementing IEEE 802.1aq Shortest Path Bridging (SPB) networks. It is principally addressed to system integrators and solution providers, including those that do not yet support SPB. Some advice to protocol implementers is also provided. The intention of the advice is to facilitate multi vendor network deployments as well as provide guidance for new installations. "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, 2014-02-14, 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. "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, 2014-02-14, 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-ccamp-rc-objective-function-metric-bound-05.txt "Customer Edge Router Identification Option", Chris Donley, Michael Kloberdans, John Brzozowski, Chris Grundemann, 2014-02-14, 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, 2014-02-13, 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. "ALTO Cost Schedule", Sabine Randriamasy, Nico Schwan, 2014-02-14, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information. This allows applications to make informed decisions, for example when selecting a target host from a set of candidates. The ALTO problem statement [RFC5693] considers typical applications as file sharing, real-time communication and live streaming peer-to-peer networks. Recently other use cases focused on Content Distribution Networks and Data Centers have emerged. The present draft proposes to extend the cost information provided by the ALTO protocol. The purpose is to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that have a degree of freedom on when to schedule data transfers, such as non- instantaneous data replication between data centers or service provisioning to end systems with irregular connectivity. The draft therefore specifies a new cost mode, called the "schedule" mode. In this mode the ALTO server offers cost maps that contain path ratings that are valid for a given timeframe (e.g. hourly) for a period of time (e.g. a day). Besides the functional time-shift enhancement providing multi-timeframe cost values, the ALTO Cost Schedule also allows to save a number of ALTO transactions and thus resources on the ALTO server and clients. Last, guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. "ALTO session for CDN Interconnection", Stephan Emile, Selim Ellouze, 2014-04-17, The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria. Various protocols, such as BGP or ALTO, may be used by a downstream CDN to expose content routing information and interconnection preferences to an upstream CDN. The selection of such a protocol is premature as the WG, and especially the Footprint/ Capabilities Design Team, is currently working on this topic. So this draft does not promote the usage of the ALTO protocol for CDN interconnection. It presents the limitations of the current ALTO protocol in the case it would be selected for CDN interconnection. It specifies the mechanism for controlling the session initialization and for limiting the information exchanged. Then it discusses the need of incremental update and proposes to study the usage of Netconf /Yang to provide ALTO server with notifications. "DS-Lite Failure Detection and Failover", Tina Tsou, Brandon Li, Cathy Zhou, Jürgen Schönwälder, Reinaldo Penno, Mohamed Boucadair, 2014-02-12, In DS-Lite, the tunnel is stateless, not associated with any state information, and the CGN function at the AFTR is stateful. Currently, there is no failure detection and failover mechanism for both stateless tunnel and stateful CGN function, which makes it difficult to manage and diagnose if there is a problem. This draft analyzes the applicability of some of the possible solutions. "TFTP Windowsize Option", Patrick Masotta, 2014-05-19, The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the early stages of nodes booting from a Local Area Network. TFTP has been always used because it is very simple to implement. However, the choice of a lock-step schema is not the most efficient for use on a LAN. This document describes a TFTP option which allows the client and server to negotiate a windowsize of consecutive blocks to send as an alternative for replacing the single block lock-step schema. The TFTP Option Extension mechanism is described in [2]. "Plasma Service Cryptographic Message Syntax (CMS) Processing", Jim Schaad, 2014-02-12, Secure MIME (S/MIME) defined a method of placing security labels on a Cryptographic Message Syntax (CMS) object. These labels are placed as part of the data signed and validated by the parties. This means that the message content is visible to the recipient prior to the label enforcement. A new model for enforcement of policy using a third party is described in RFC TBD [I-D.freeman-plasma-requirements]. This is the Policy Augmented S/ MIME (PLASMA) system. This document provides the details needed to implement the new Plasma model in the CMS infrastructure. An additional benefit of using the Plasma module is that the server, based on policy, manages who has access to the message and how the keys are protected. The document details how the client encryption and decryption processes are performed, defines how to construct the CMS recipient info structure, a new content to hold the data required for the Plasma server to store the keys and policy information. The document does not cover the protocol between the client and the Plasma policy enforcement server. One example of the client/server protocol can be found in RFC TBD [I-D.schaad-plasma-service]. "LISP-DDT Referral Internet Groper (RIG)", Dino Farinacci, Amit Jain, Isidor Kouvelas, Darrel Lewis, 2014-03-17, 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, 2014-03-24, 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. "Definitions of Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, Senthil Sivakumar, 2014-01-24, This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. This document obsoletes RFC 4008. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, Toby Moncaster, Alan Smith, 2014-03-11, This document introduces re-ECN (re-inserted explicit congestion notification), which is intended to make a simple but far-reaching change to the Internet architecture. The sender uses the IP header to reveal the congestion that it expects on the end-to-end path. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. It can be deployed incrementally around unmodified routers. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond sufficiently to congestion, but these are described more fully in a companion document. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. "Re-ECN: A Framework for adding Congestion Accountability to TCP/IP", Bob Briscoe, Arnaud Jacquet, Toby Moncaster, Alan Smith, 2014-03-11, This document describes a framework for using a new protocol called re-ECN (re-inserted explicit congestion notification), which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to use the protocol honestly. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. "Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sami Boutros, Sam Aldrin, 2014-06-18, 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. "SA46T Address Translator", Naoki Matsuhira, Katsuhiro Horiba, Yukito Ueno, Osamu Nakamura, 2014-02-13, 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. "Supercharged Codes", Erik Stauffer, BZ Shen, Soumen Chakraborty, Djordje Tujkovic, Jing Huang, Shiv Shet, Kamlesh Rath, 2014-03-27, This document describes a fully-specified FEC scheme for the Supercharged forward error correction code. Supercharged codes are designed for use on the erasure channel. Coding for the erasure channel commonly arises for data transmission over the internet, where lower layers either successfully deliver packets or fail to deliver them. Coding is required to insure that data is not lost, even if packets are lost at the lower layers. Error free reception is important for multimedia applications, such as streaming, where it may not be possible to correct an error in time by any other means. Coding insures that lost packets can be recovered. "6rd Tunnel MTU", Fred Templin, 2014-02-14, The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE) routers is currently recommended to be set to 1480. This is to avoid IPv4 fragmentation within the tunnel, but requires the tunnel ingress to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction somewhere in the Internet. Fortunately, the "Internet cell size" is 1500 bytes (i.e., the minimum MTU configured by the vast majority of links in the Internet) so if the 6rd PE router can set a tunnel MTU of at least 1500 bytes the MTU issues are alleviated. This document specifies methods that can be employed to support these larger sizes. "Network Architecture with Recursive Addressing", Chungnam University, 2014-06-19, A network architecture based on recursive addressing is proposed. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by an exterior address whereas each node by an interior local address. Exterior routing depends solely on site addresses while interior routing on node addresses. Mobility is inherent in Interior routing while migration and multihoming are in exterior routing. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter-planetary as well as Internet of Things. "BGP Remote-Next-Hop", Gunter Van de Velde, Keyur Patel, Dhananjaya Rao, Robert Raszuk, Randy Bush, 2014-01-17, The BGP Remote-Next-Hop is a new optional transitive attribute intended to facilitate automatic tunneling across an AS on a per address family basis. The attribute carries one or more tunnel end- points for a NLRI. Additionally, tunnel encapsulation information is communicated to successfully setup these tunnels. "Responsible Grandparenting in the RPKI", Randy Bush, 2014-02-04, There are circumstances in RPKI operations where a resource holder's parent may not be able to, or may not choose to, facilitate full and proper registration of the holder's data. As in real life, the holder may form a relationship with their grandparent who is willing to aid the grandchild. This document describes simple procedures for doing so. "Authenticated Encryption with AES-CBC and HMAC-SHA", David McGrew, John Foley, Kenny Paterson, 2014-02-14, This document specifies algorithms for authenticated encryption with associated data (AEAD) that are based on the composition of the Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) mode of operation for encryption, and the HMAC-SHA message authentication code (MAC). These are randomized encryption algorithms, and thus are suitable for use with applications that cannot provide distinct nonces to each invocation of the AEAD encrypt operation. "An HTTP Status Code to Report Legal Obstacles", Tim Bray, 2014-01-06, This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied due to legal demands. "DNS Extension for Autonomous Internet(AIP)", Diao Yuping, Diao Yongping, Ming Liao, 2014-06-24, 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. "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. "Indication of support for reverse keep-alive", Christer Holmberg, Oscar Gallego, 2014-06-16, This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "rkeep". The "rkeep" parameter allows a SIP entity to indicate willingness to receive keep-alives from its adjacent downstream SIP entity, the adjacent downstream SIP entity to indicate willingness to send keep-alives, and for SIP entities willing to send keep-alives to inform the receiver about the keep- alive interval. "An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, 2014-02-07, 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 Optical parameters associated with Dense Wavelength Division Multiplexing (DWDM) interfaces. This is an extension of the RFC3591 to support the optical parameters described in ITU-T G.698.2. [ITU.G698.2] The MIB module defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of Black Links. "OmniBroker Protocol", Phillip Hallam-Baker, 2014-05-19, An Omnibroker is an agent chosen and trusted by an Internet user to provide information such as name and certificate status information that are in general trusted even if they are not trustworthy. Rather than acting as a mere conduit for information provided by existing services, an Omnibroker is responsible for curating those sources to protect the user. The Omnibroker Protocol (OBP) provides an aggregated interface to trusted Internet services including DNS, OCSP and various forms of authentication service. Multiple transport bindings are supported to permit efficient access in virtually every common deployment scenario and ensure access in any deployment scenario in which access is not being purposely denied. "VPWS support in E-VPN", Sami Boutros, Ali Sajassi, Samer Salam, John Drake, Jeff Tantsura, Dirk Steinberg, 2014-02-14, This document describes how E-VPN can be used to support virtual private wire service (VPWS) in MPLS/IP networks. E-VPN 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. "The Link-Template HTTP Header Field", Mark Nottingham, 2013-12-31, This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. "Managing and removing automatic version rollback in TLS Clients", Yngve Pettersen, 2014-02-12, Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use. "Practices for scaling ARP and ND for large data centers", Linda Dunbar, Warren Kumari, Igor Gashinsky, 2014-05-07, This draft documents some operational practices that allow ARP/ND to scale in data center environments. "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, 2014-01-31, This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. "Advanced Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2014-06-22, This draft describes advanced features for HTTP-CoAP proxy implementors. 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, 2014-01-02, 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]. "Enhanced Sleepy Node Support for CoAP", Akbar Rahman, 2014-02-11, CoAP is a specialized web transfer protocol for constrained devices. These devices typically have some combination of limited battery power, small memory footprint and low throughput links. It is expected that in CoAP networks there will be a certain portion of devices that are "sleepy" and which may occasionally go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend CoAP protocol communication. This document proposes a minimal and efficient mechanism building on the Resource Directory (RD) functionality to enhance sleepy node support in CoAP networks. The RD functionality may be incorporated as part of a CoAP Proxy. "Using Port Control Protocol (PCP) to update dynamic DNS", Xiaohong Deng, Mohamed Boucadair, Qin Zhao, Jing Huang, Cathy Zhou, 2014-06-11, This document focuses on the problems encountered when using dynamic DNS in address sharing contexts (e.g., DS-Lite, NAT64) during IPv6 transition. Both issues and possible solutions are documented in this memo. "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari, Kotikalapudi Sriram, 2014-01-06, 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. "Opportunistic Routing based on Users Daily Life Routine", Waldir Moreira, Paulo Mendes, Eduardo Cerqueira, 2014-05-08, This document is written in the context of the Delay Tolerant Networking Research Group and will be presented for reviewing by that group. This document defines dLife, an opportunistic routing protocol that takes advantage of time-evolving social structures. dLife belongs to the family of social-aware opportunistic routing protocols for intermittently connected networks. dLife operates based on a representation of the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different periods of time. It considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of user's importance, based on its node degree and the social strength towards its neighbors, in different periods of time. It is intended for use in wireless networks where there is no guarantee that a fully connected path between any source - destination pair exists at any time, a scenario where traditional routing protocols are unable to deliver bundles. Such networks can be sparse mesh, in which case intermittent connectivity is due to lack of physical connections, or dense mesh, in which case intermittent connectivity may be due to high interference or shadowing. In any case, intermittent connectivity can also be due to the availability of devices (e.g., unavailable due to power saving rules). The document presents an architectural overview followed by the protocol specification. "Mapping 802.11 QoS in a PMIPv6 Mobility Domain", John Kaippallimalil, Rajesh Pazhyannur, Parviz Yegani, 2014-02-11, This document provides recommendations on procedures and mapping of QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 that reserve resources for 802.11 streams should be mapped to PMIP QoS resources for IP sessions and flows. QoS reservation sequences in 802.11 should allow cases where MN initiate resource reservation, as well as cases where the network initiates resource reservation. Additionally, it should be possible for QoS parameters for PMIPv6 flows and mobility sessions to be mapped to 802.11 traffic stream reservations. The sequences and parameters to be mapped to provide a consistent behavior across 802.11 and PMIPv6 QoS are described here. "HyperText Markup Language Request For Comments Format", Joe Hildebrand, Heather Flanagan, 2014-06-06, This document defines the HTML format that should be used for the production of Internet-Drafts and RFCs. The HTML output will include a default CSS to enable page layout, and the HTML itself includes semantic information only. This format will be rendered from the canonical XML format for an RFC. "PPSP Tracker Protocol-Extended Protocol", Rui Cruz, Rachel Huang, Ning Zong, Mario Nunes, Joao Taveira, 2014-01-23, This document specifies an extended Peer-to-Peer Streaming Protocol - Tracker Protocol, which is a new extension protocol complementing the basic core messages and usages specified in the base tracker protocol for the exchange of meta information between trackers and peers, such as initial offer/request of participation in multimedia content streaming, content information, peer lists and reports of activity and status. It extends the base tracker protocol to include new optional messages providing new usages in the communications between peer and tracker. The extension protocol is retro-compatible with the base tracker protocol. "ALTO Extensions for Collecting Data Center Resource Information", Young Lee, Greg Bernstein, Dhruv Dhody, Taesang Choi, 2014-01-06, In a networked application environment where resources (e.g., computing, storage, etc.) are geographically distributed in Data Centers, a key decision is to allocate the application request to an "optimal" Data Center location in which to host the application request. Key constraints in this decision include resource availability, network cost, infrastructure constraints (e.g., power) and others. This draft proposes an ALTO extension to support data center resource information model and its related protocol extensions. "", Takuo Suganuma, Naoki Nakamura, Satoru Izumi, Hiroshi Tsunoda, Masahiro Matsuda, Kohei Ohta, 2014-01-11, 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, 2014-01-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 Attribute for 4rd", Sheng Jiang, Yu Fu, Bing Liu, 2014-02-14, IPv4 Residual Deployment via IPv6 (4rd) 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) 4rd options has been defined to configure 4rd 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 4rd configuration information from AAA server to BNG. The 4rd RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 4rd option. "RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Qian Wang, Wei Meng, Cui Wang, Mohamed Boucadair, 2014-04-10, 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_PREFIX64 option. "A Routing Request Extension for the HELD Protocol", James Winterbottom, Hannes Tschofenig, Laura Liess, 2014-05-29, In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. In such environments the general ECRIT calling models breakdown. However, location servers operating in these areas are often privy to the necessary information to reach emergency and other services. This document describes a solution where by the routing information may be obtained from a location server using a simple extension to the HELD protocol. "The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage", John Bradley, Phil Hunt, Anthony Nadalin, Hannes Tschofenig, 2014-01-13, OAuth 2.0 deployments currently rely on bearer tokens for securing access to protected resources. Bearer tokens require Transport Layer Security to be used between an OAuth client and the resource server when presenting the access token. The security model is based on proof-of-possession: access token storage and transfer has to be done with care to prevent leakage. There are, however, use cases that require a more active involvement of the OAuth client for an increased level of security, particularly to secure against token leakage. This document specifies an OAuth security framework using the holder-of-the-key concept, which requires the OAuth client when presenting an OAuth access token to also demonstrate knowledge of keying material that is bound to the token. "Third-Party ALTO Server Discovery (3pdisc)", Sebastian Kiesel, Kilian Krause, Martin Stiemerling, 2014-01-13, 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. This document specifies a procedure for third-party ALTO server discovery, which can be used if the ALTO client is not co-located with the actual resource consumer, but instead embedded in a third party such as a peer-to-peer tracker. 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 several DNS lookups (for U-NAPTR and SOA resource records) and returns one or more URI(s) of information resources related to that IP address. "LISP Replication Engineering", Florin Coras, Albert Cabellos-Aparicio, Jordi Domingo-Pascual, Fabio Maino, Dino Farinacci, 2014-04-23, 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. "Publish Option for CoAP", Thomas Fossati, Pierpaolo Giacomin, Salvatore Loreto, 2014-01-06, This memo defines the Publish Option for the Constrained Application Protocol (CoAP). The Publish Option is used by a CoAP Endpoint to control the authority delegation of one of its resources to another Endpoint. All the phases of the authority delegation process (setup, renewal, cancellation) are controlled by a simple RESTful protocol. This memo also introduces the 'proxies' Web Linking relation type, to be used by a CoAP Proxy to explicitly advertise the resources that it can serve - either from its cache, or by forwarding the Client's request upstream. The Publish Option and the 'proxies' relation provide the building blocks for a comprehensive, in-protocol, solution to the sleepy/ intermittent Endpoint use case. "Mobility with ICE (MICE)", Dan Wing, Tirumaleswar Reddy, Prashanth Patil, Paal-Erik Martinsen, 2014-06-17, This specification describes how endpoint mobility can be achieved using ICE. "WebSocket-based server-to-client notifications for the Application-Layer Traffic Optimization (ALTO) Protocol", Enrico Marocco, Jan Seedorf, 2014-02-14, 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. The base protocol specification adopts a simple pull-based model, according to which the client retrieves the information encoded as JSON objects over HTTP directly from the server. This document proposes (for discussion) a mechanism for providing server-initiated information update notifications through a WebSocket-based ALTO protocol extension that easily integrates in the basic protocol model. "Performance Issues with MPTCP", Ramin Khalili, Nicolas Gast, Miroslav Popovic, Jean-Yves Le Boudec, 2014-02-14, We show, by measurements over a testbed and by mathematical analysis, that the current MPTCP suffers from two problems: (P1) Upgrading some TCP users to MPTCP can reduce the throughput of others without any benefit to the upgraded users; and (P2) MPTCP users can be excessively aggressive towards TCP users. We attribute these problems to the "Linked Increases" Algorithm (LIA) of MPTCP [4], and more specifically, to an excessive amount of traffic transmitted over congested paths. Our results show that these problems are important and can be mitigated. We believe that the design of the congestion control of MPTCP should be improved. "Multipath RTP (MPRTP) attribute in Session Description Protocol", Varun Singh, Joerg Ott, Teemu Karkkainen, Ralf Globisch, Thomas Schierl, 2014-01-13, Multipath RTP (MPRTP) is an extension to the Real-time Transport Protocol (RTP) that allows multi-homed endpoints to take advantage of the availability of multiple Internet paths between endpoints to send /receive media packets. This document describes how to express the interface advertisement and negotiation during session setup in SDP (Session Description Protocol). "LSP-Ping Mechanisms for E-VPN and PBB-EVPN", Parag Jain, Sami Boutros, Samer Salam, 2014-06-17, 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 E-VPN and PBB-EVPN networks. "Use of BGP for routing in large-scale data centers", Petr Lapukhov, Ariff Premji, Jon Mitchell, 2014-02-06, 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. "Shared Memory Communications over RDMA", Mike Fox, Constantinos Kassimis, Jerry Stevens, 2014-05-09, This document describes the 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. "Framework for Point-to-Multipoint MPLS-TP OAM", Kaoru Arai, Yoshinori Koike, Takafumi Hamano, Masatoshi Namiki, 2014-01-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 draft-mpls- tp-p2mp-framework. 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. "LISP Control-Plane Multicast Signaling", Dino Farinacci, Maria Napierala, 2014-03-03, 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. "Network Performance Isolation in Data Centres using Congestion Policing", Bob Briscoe, Murari Sridharan, 2014-02-14, This document describes how a multi-tenant (or multi-department) data centre operator can isolate tenants from network performance degradation due to each other's usage, but without losing the multiplexing benefits of a LAN-style network where anyone can use any amount of any resource. Zero per-tenant configuration and no implementation change is required on network equipment. Instead the solution is implemented with a simple change to the hypervisor (or container) beneath the tenant's virtual machines on every physical server connected to the network. These collectively enforce a very simple distributed contract - a single network allowance that each tenant can allocate among their virtual machines, even if distributed around the network. The solution uses layer-3 switches that support explicit congestion notification (ECN). It is best if the sending operating system supports congestion exposure (ConEx). Nonetheless, the operator can unilaterally deploy a complete solution while operating systems are being incrementally upgraded to support ConEx and ECN. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage application code of optical interface parameters in DWDM application", Dharini Hiremagalur, Gert Grammel, John Drake, Gabriele Galimberti, Zafar Ali, Ruediger Kunze, 2014-06-18, 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 extendsions./> "Transparent SDH/SONET over Packet", Gert Manhoudt, Stephan Roullot, Kin Wong, 2014-02-03, 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. "KARP KMP: Simplified Peer Authentication", Uma Chunduri, Albert Tian, Ari Keranen, Tero Kivinen, 2014-05-27, This document describes the usage of Router Fingerprint Authentication (RFA) with public keys as a potential peer authentication method with KARP pair wise and group Key Management Protocols (KMPs). The advantage of RFA is, it neither requires out- of-band, mutually agreeable symmetric keys nor a full PKI based system (trust anchor or CA certificates) for mutual authentication of peers with KARP KMP deployments. Usage of Router Fingerprints give a significant operational improvement from symmetric key based systems and yet provide a secure authentication technique. "Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation", Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Andrea Zanardi, Domenico Siracusa, 2014-02-12, This document defines an information model to support Impairment- Aware (IA) Routing and Wavelength Assignment (RWA) function. This operation might be required in Wavelength Switched Optical Networks (WSON) that already support RWA and the information model defined here goes in addition and it is fully compatible with the already defined information model for impairment-free RWA process in WSON. This information model shall support all control plane architectural options defined for WSON with impairment validation. "Information Encoding for WSON with Impairments Validation", Giovanni Martinelli, Domenico Siracusa, Xian Zhang, Gabriele Galimberti, Andrea Zanardi, 2014-02-12, 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. "Guidelines for Writing an IANA Considerations Section in RFCs", Michelle Cotton, Barry Leiba, Thomas Narten, 2014-06-03, 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, 2014-06-23, 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. "CoAP Simple Congestion Control/Advanced", Carsten Bormann, 2014-02-14, The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. In the present version -01, it is already making use of some input from simulations, but might still benefit from simplifying it further. "LLCPS", Pascal Urien, 2014-01-10, 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, 2014-03-04, This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the HIP Base EXchange (HIP BEX) [rfc5201-bis]. 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 HIP BEX. The HIP DEX protocol is primarily targeted at computation or memory- constrained sensor devices. Like HIP BEX, it is expected to be used together with another suitable security protocol such as the Encapsulated Security Payload (ESP) [rfc5202-bis] for the protection of upper layer protocols. HIP DEX can also be used as a keying mechanism for a MAC layer security protocol as is supported by IEEE 802.15.4 [IEEE.802-15-4.2011]. "RPL Routing Pathology In a Network With a Mix of Nodes Operating in Storing and Non-Storing Modes", JeongGil Ko, Jongsoo Jeong, Jongjun Park, Jong Jun, Naesoo Kim, Omprakash Gnawali, 2014-02-11, The RPL specification allows nodes running with storing or non- storing modes to operate in the same network. We describe how such a mix can result in network partitioning even when there are plenty of physical links available in the network. The partitioning affects both upwards (nodes to root) and downwards (root to leaf) traffic. This routing pathology stems from a recommendation made in the RPL specification forcing nodes with different modes of operation to join the RPL network as leaf nodes only. We propose a solution that modifies RPL by mandating that all the nodes parse and interpret source routing headers and storing mode nodes to sometimes act like a non-storing mode root by attaching source routing headers. "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 2014-04-18, This document describes a cryptographic authentication mechanism for Babel routing protocol, updating, but not superseding RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses HMAC and is both optional and backward compatible. "Military Message Handling System (MMHS) over SMTP", Alexey Melnikov, Graeme Lunt, Alan Ross, 2014-01-07, A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 or ACP 123. This document specifies how a comparable messaging service can be provided using Internet Electronic Mail, SMTP and their extensions. "ENUM Service Registration for acct URI", Laurent Goix, Kepeng Li, 2014-06-18, This document registers a Telephone Number Mapping (ENUM) service for 'acct:' URIs (Uniform Resource Identifiers). "SCIM and vCard mapping", Bert Greevenbosch, 2014-02-12, This document defines a mapping between SCIM and vCard. Note Discussion and suggestions for improvement are requested, and should be sent to scim@ietf.org. "IP Connectivity Provisioning Profile (CPP)", Mohamed Boucadair, Christian Jacquenet, Ning Wang, 2014-04-11, This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics such as one-way delay or one-way delay variation are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. "Design Discussion and Comparison of Replay-Attack Protection Mechanisms for BGPSEC", Kotikalapudi Sriram, Doug Montgomery, 2014-03-25, The BGPSEC protocol requires a method for protection from replay attacks, at least to control the window of exposure. In the context of BGPSEC, a replay attack occurs when an adversary suppresses a prefix withdrawal (implicit or explicit) or replays a previously received BGPSEC announcement for a prefix that has since been withdrawn. This informational document provides design discussion and comparison of multiple alternative replay-attack protection mechanisms weighing their pros and cons. It is meant to be a companion document to the standards track I-D.-ietf-sidr-bgpsec- rollover that will specify a method to be used with BGPSEC for replay-attack protection. "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Wesley George, Shane Amante, 2014-01-06, This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. "Multihoming in Homenet", Wassim Haddad, Damien Saucez, 2014-04-01, 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, 2014-01-07, 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]. "Use cases for MAP-T", Roberta Maglione, Wojciech Dec, Ida Leung, Edwin Mallette, 2014-04-10, The Softwire working group is currently discussing both encapsulation and translation based stateless IPv4/IPv6 solutions in order to be able to provide IPv4 connectivity to customers in an IPv6-Only environment. The purpose of this document is to describe some operational use cases that would benefit from a translation based approach and highlights the operational benefits that a translation based solution would allow. "Happy Eyeballs Extension for ICE", Tirumaleswar Reddy, Prashanth Patil, Paal-Erik Martinsen, 2014-02-14, This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in IPv4/IPv6 dual- stack scenarios where broken paths exist. "Parallel NFS (pNFS) Lustre Layout Operations", Sorin Faibish, Dominique Cote, Peng Tao, 2014-05-02, Parallel NFS (pNFS) extends Network File System version 4.1(NFSv4.1) to allow clients to directly access file data on the storage used by the NFSv4.1 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, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout-type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Lustre pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. "HTTP Link and Unlink Methods", James Snell, 2014-05-26, This specification defines the semantics of the LINK and UNLINK HTTP methods. "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. "Quick Start Plus", Randall Stewart, Michael Tuexen, 2014-01-15, This document describes an extension to Quick Start including the missing Stream Control Transmission Protocol (SCTP) QuickStart chunk types and procedures so that SCTP may also use the QuickStart extension. "Host Identification: Use Cases", Mohamed Boucadair, David Binet, Sophie Durel, Bruno Chatras, Tirumaleswar Reddy, Brandon Williams, Behcet Sarikaya, Li Xue, 2014-04-11, This document describes a set of scenarios in which host identification is problematic. The document does not include any solution-specific discussion. "ForCES Inter-FE LFB", DJ, Jamal Hadi Salim, 2014-01-13, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model which provides a formal way to represent the capabilities, state, and configuration of forwarding elements(FEs) within the context of the ForCES protocol. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. The control elements (CEs) can control the FEs using the ForCES model definition. The ForCES WG charter has been extended to allow the LFB topology to be across FEs. This documents describes a non-intrusive way to extend the LFB topology across FEs. "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", Samita Chakrabarti, Erik Nordmark, Pascal Thubert, Margaret Wasserman, 2014-02-14, 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. "Hybrid Measurement using IPPM Metrics", Brian Trammell, Lianshu Zheng, Sofía Berenguer, Marcelo Bagnulo, 2014-02-14, Hybrid measurement is the combination of metrics derived from passive and active measurement to produce a measurement result. This document discusses use cases for hybrid measurement using metrics defined within the IPPM framework, and discusses requirements for the definition of passive methodologies for selected IPPM metrics. "Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs", Mike Taillon, Tarek Saad, Rakesh Gandhi, Zafar Ali, Manav Bhatia, Lizhong Jin, Frederic JOUNAY, 2014-03-06, This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of bidirectional co-routed Packet Switched Capable (PSC) 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. 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. "URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le Faucheur, Bill Downey, Ray van Brandenburg, Scott Leibrand, 2014-03-04, This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 2014-03-21, 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 -03 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. "Bootstrapping Trust on a Homenet", Michael Behringer, Max Pritikin, Steinthor Bjarnason, 2014-02-14, A homenet must be aware of its borders, and the realms within those. This document proposes an approach to bootstrap trust in such an environment. The idea is to select one device as the trust anchor and to enrol other devices into the domain. The result is the creation of a domain of trust in the homenet, with a common trust anchor. This trust model can subsequently be used to determine boundaries, and to autonomically bootstrap network services. "A Framework for L3VPN Performance Monitoring", Jie Dong, Zhenbin Li, Bhavani Parise, 2014-01-16, The capability of BGP/MPLS IP Virtual Private Networks (L3VPN) performance monitoring (PM) is important to meet the Service Level Agreement(SLA) for the service beared. Since multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge for L3VPN PM. This document specifies the framework and mechanisms for the application of L3VPN PM. "The eduroam architecture for network roaming", Klaas Wierenga, Stefan Winter, Tomasz Wolniewicz, 2014-02-14, 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 and the changes that were prompted by operational experience are highlighted. "A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs", Zhenbin Li, Jie Dong, 2014-01-16, MPLS TE has been widely deployed to provide traffic engineering and traffic protection. The complexity in configuration has much effect on the MPLS TE deployment in the large-scale network. The document identifies the configuration issues for MPLS TE deployment and proposes a new mechanism, the service-driven mechanism, by which the setup of co-routed MPLS TE LSPs is triggered by the bidirectional service. Then the document provides the framework for setting up service-driven co-routed MPLS Traffic-Engineered Label-Switched Paths(TE LSPs) for L2VPN and L3VPN. "Multi-Path Time Synchronization", Alex Shpiner, Richard Tse, Craig Schelp, Tal Mizrahi, 2014-02-11, 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 protection. 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. "LISP Impact", Damien Saucez, Luigi Iannone, Florin Coras, 2014-03-02, 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, deployment, and theoretical studies, we discuss the impact that deployment of LISP can have on both the Internet in general and for the end-users in particular. "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, 2014-06-13, 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, 2014-02-12, 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 the RFC 3264 [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. "Tree Notification to Improve Multicast Fast Reroute", IJsbrand Wijnands, Luc De Ghein, Gabor Envedi, Andras Csaszar, Jeff Tantsura, 2014-01-24, This draft proposes dataplane triggered Tree Notifications to support multicast fast reroute for PIM and mLDP. These Tree Notifications are initiated by a node detecting the failure to a Repair Node downstream. A Repair Node is a node that has a pre-built backup path that can circumvent the failure. Using this mechanism, a Repair Node has the ability to learn about non-local failures quickly without having to wait for the IGP to convergence. This draft also covers an optional method to avoid bandwidth usage on the pre-built backup path. "E-VPN Operations, Administration and Maintenance Requirements and Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, 2014-01-23, This document specifies the requirements and reference framework for Ethernet VPN (E-VPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of E-VPN, PBB-EVPN and TRILL-EVPN. The framework defines the layered OAM model encompassing the E-VPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. "CGA-TSIG: An Algorithm for Secure DNS Authentication and DNS Confidentiality", Hosnieh, Martin von Loewis, Christoph Meinel, 2014-06-02, This document describes a new mechanism for secure DNS authentication and DNS data confidentiality. The purpose of this document is to reduce human interaction during different DNS scenarios such as the communications of resolvers to stub resolvers, recursive resolvers to Authoritative Name Server, Dynamic DNS updates, (especially updating PTR and FQDN records (RFC4703)) and zone transfers. This document also considered for the support of both IPv4 and IPv6. "Transport Layer Security (TLS) Authorization Using DTCP Certificate", Darshak Thakore, 2014-01-30, This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) Protocol. This is in accordance with the guidelines for authorization extensions as specified in [RFC5878]. As with other TLS extensions, this authorization data can be included in the client and server Hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC4680. This authorization data type extension is in support of devices containing DTCP certificates, issued by the Digital Transmission Licensing Administrator [DTLA]. "Distributed Mobility Management - Framework & Analysis", Marco Liebsch, Pierrick Seite, Georgios Karagiannis, Sri Gundavelli, 2014-02-14, Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. The Distributed Mobility Management (DMM) Working Group is investigating the impact of decentralized mobility management to existing protocol solutions, while taking into account well defined requirements, which are to be met by a future solution. This document discusses DMM using a functional framework. Functional Entities to support DMM as well as reference points between these Functional Entities are introduced and described. The described functional framework allows distribution and co-location of Functional Entities and build a DMM architecture that matches the architecture of available protocols. Such methodology eases the analysis of best current practices with regard to functional and protocol gaps. "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. "NADA: A Unified Congestion Control Scheme for Real-Time Media", Xiaoqing Zhu, Rong Pan, 2014-03-13, This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network node operations. Results from extensive simulation studies of the proposed scheme are available upon request. "H.264 as Mandatory to Implement Video Codec for WebRTC", BoB, Markus Isomaki, Bernard Aboba, Gaelle Martin-Cocher, Giridhar Mandyam, Xavier Marjou, Cullen Jennings, Jonathan Rosenberg, David Singer, 2014-04-25, This document proposes that, and motivates why, H.264 should be a Mandatory To Implement video codec for WebRTC. "RSVP-TE Signaling For GMPLS Restoration LSP", Rakesh Gandhi, Zafar Ali, Gabriele Galimberti, Xian Zhang, 2014-04-23, 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. 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 when using restoration LSP where failed LSP is not torn down. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. "Experience from Double Translation and Encapsulation (MAP) Testing", Xiaohan Liu, Baoping Yan, Congxiao Bao, Xing Li, 2014-03-02, This document discusses the experiences of using Mapping of Address and Port (MAP). Network setup and testing results using MAP-Translation (MAP-T), MAP- Encapsulation (MAP-E) and mixed MAP-T/MAP-E are described in this document. Relationships among native IPv6, single translation, double translation, and encapsulation are also discussed. "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, 2014-05-13, 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. The SignWriting Text encoding model defines the structures of SignWriting Block Printing. The plain-text mathematical names are explained with tokens and regular expressions patterns. The visual image is supported with SVG and PNG generated by a SignWriting Icon Server. An experimental TrueType Font is available. Formal SignWriting strings define a lite ASCII markup to name each sign logogram. The text is defined with regular expressions. The included query language defines several productive searching possibilities. The transformation from query language to regular expression is defined. For Unicode, the current use of the Private Use Area font characters is documented. A character proposal for plane 1 is included that is isomorphic with the characters that are currently used by the community. 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. "DSCP and other packet markings for RTCWeb QoS", Subha Dhesikan, Cullen Jennings, Dan Druta, Paul Jones, James Polk, 2014-06-22, Many networks, such as service provider and enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. "Multicast Issues in Networks Using NVO3", Anoop Ghanwani, Linda Dunbar, Vinay Bannai, ramki, 2014-02-13, This memo discusses issues with supporting multicast traffic in a network that uses Network Virtualization using Overlays over Layer 3 (NVO3). It describes the various mechanisms that may be used for multicast and discusses some of the considerations with supporting multicast applications in networks that use NVO3. "A PCE-based Architecture for Application-based Network Operations", Daniel King, Adrian Farrel, 2014-02-13, Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet this type of requirement is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies for gathering information about the resources available in a network, for consideration of topologies and how those topologies map to underlying network resources, for requesting path computation, and for provisioning or reserving network resources. Thus, ABNO may be seen as the use of a toolbox of existing components enhanced with a few new elements. The key component within an ABNO is the Path Computation Element (PCE), which can be used for computing paths and is further extended to provide policy enforcement capabilities for ABNO. This document describes an architecture and framework for ABNO showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. "remoteStorage", Michiel de Jong, F. Kooman, 2014-06-13, 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. "Via header field parameter to indicate received realm", Christer Holmberg, Yi Jiang, 2014-06-16, 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. "Compact representation of an elliptic curve point", Andrey Jivsov, 2014-03-15, This document defines a format for efficient storage representation of an elliptic curve point over prime fields, suitable for use with any IETF format or protocol. "Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows", Mirko Suznjevic, Jose Saldana, 2014-06-10, This document contains recommendations to be taken into account when using methods which optimize bandwidth utilization through compression, multiplexing, and tunneling traffic flows (TCM-TF) 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-TF. 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, 2014-02-14, 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. "Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class 'mailboxRelatedObject'", Michael Stroeder, 2014-02-03, This document defines the auxiliary object class 'mailboxRelatedObject' that can be used to associate an arbitrary object with an Internet mail address. Furthermore an attribute 'intlMailAdr' is defined for storing fully internationalized Internet mail addresses. "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, Victor Pascual, Anton Roman, Gonzalo Salgueiro, 2014-02-13, 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, 2014-06-11, 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. "Traffic Management Benchmarking", Barry Constantine, Timothy Copley, Ram Krishnan, 2014-02-10, 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. "TRILL: Parent Selection in Distribution Trees", Howard Yang, Ayan Banerjee, Donald Eastlake, Radia Perlman, 2014-01-06, 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. "ICN Wireless Sensor and Actor Network BaseLine Scenarios", Ngoc-Thanh Dinh, Young-Han Kim, xuan@dcn.ssu.ac.kr, 2013-12-28, This document presents scenarios for information centric wireless sensor and actor networks. The scenarios selected for inclusion in this first draft aim to exercise a variety of aspects in wireless sensor and actor network that an ICN solution could address. "A Media Type for XML Patch Operations", Erik Wilde, 2014-06-10, The XML Patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML Patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML Patch documents in, for example, HTTP conversations. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. "The problem statement of RBridge edge group state synchronization", Hao Weiguo, Li Yizhou, Liang Xia, ZTE Corporation, 2014-06-05, In TRILL multi-homing scenario, the concept of virtual RBridge in [TRILLPN], was introduced to address the MAC flip-flopping problem at remote RBridges. Based on virtual RBridge mechanism, Coordinated Multicast Trees (CMT) solution in [CMT] was introduced to solve the related RPF issues. In this document, additional problems are described regarding virtual Bridges members' state synchronization in multi-homing scenario, including virtual RBridge membership auto discovery, pseudo-nickname static configuration consistency check, dynamic pseudo-nickname allocation, CMT configuration synchronization ,LACP configuration and state synchronization, node/link failure detection, MAC table synchronization, DHCP snooping information, and dynamically joined VLANs and multicast groups. To address these problems, a communication protocol among members of a virtual RBridge group should be provided. Requirements for this protocol are also discussed. "PLASMA and Redacted Documents", Jim Schaad, 2014-02-14, Redacted documents are designed to have a single document which allows different individuals to view different portions of the document basd on the attributes of the individual. In this document, a protocol extension to the basic PLASMA protocol is described that allows for multiple keys, each with a different policy, to be used in a single electronic document for enforcement of redaction levels. This document is agnostic relative to the actual format of the redacted document, the only requirement being that the redacted document be able to carry the PLASMA defined lock box. "Autonomous Extensible Internet with Network Address Multiplexing(AEIP NAM)", Diao Yuping, Diao Yongping, Ming Liao, 2014-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, 2014-05-07, 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. "Writing I-Ds and RFCs using Pandoc and a bit of XML", R. Gieben, 2013-10-15, This document presents a technique for using a Markdown syntax variant, called Pandoc, and a (bit) of XML [RFC2629] as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. The goal of this technique is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags, it does however not alleviate the need to typeset some files in XML. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Cyrus Daboo, Mike Douglass, 2014-05-12, This specification introduces a new iCalendar component which allows for consensus scheduling, that is voting on a number of alternative meeting or task alternatives. "Binding Obligations on User-Managed Access (UMA) Participants", Eve Maler, Thomas Hardjono, 2014-01-27, 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. "IGP Extensions for Stateful PCE Discovery", Siva Sivabalan, Jan Medved, Xian Zhang, 2014-01-12, When a 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. Such IGP extensions exist for OSPF and ISIS. This document specifies two new PCE capabilities advertised by IGP. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Enrico Marocco, Christer Holmberg, 2014-06-17, 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). "Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)", Alan DeKok, 2014-06-24, RADIUS specifications have used data types for two decades, without rigorously defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them as managed entities in attribute definitions. This document updates the specifications to match established practice. We do this by naming 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. "Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication", Hannes Tschofenig, Lars Eggert, Zaheduzzaman Sarker, 2014-05-14, This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB) or the Internet Research Task Force (IRTF). "Plan to Establish a Wisdom Task Force", Norbert Bollow, 2014-03-03, This memo calls for the creation of a new governance forum named "Wisdom Task Force" (WisdomTF). The main purpose of the WisdomTF is to facilitate consensus-seeking strategy-oriented discussions regarding governance actions that may be decided by national parliaments. "ICN Research Challenges", Dirk Kutscher, Suyong Eum, Kostas Pentikousis, Ioannis Psaras, Daniel Corujo, Damien Saucez, Thomas Schmidt, Matthias Waehlisch, 2014-02-14, 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. "Authentication Context Certificate Extension", Stefan Santesson, 2014-05-05, 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]. "The Virtual Private Network (VPN) Service in ALTO: Use Cases, Requirements and Extensions", Michael Scharf, Vijay Gurbani, Greg Soprovich, Volker Hilt, 2014-02-13, 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 resources from a candidate set. This document provides motivation for using ALTO in a Virtual Private Network (VPN) environment. We discuss use cases, requirements, and possible extensions to the base ALTO protocol that will be needed to support VPN services. "Reporting Equivalent IPFIX Information Elements", Paul Aitken, 2013-12-27, This document specifies a method for an IPFIX Exporting Process to inform an IPFIX Collecting Process of equivalence between different Information Elements, so that the Collecting Process can understand the equivalence and be enabled to process data across a change of Information Elements. "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. "PAWS Database Discovery", Xinpeng Wei, Lei Zhu, 2014-01-09, This document provides a Database Discovery mechanism for PAWS. By this mechanism the master device gets the available WSDBs it can communicate. "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Gang Chen, Tina Tsou, Chris Donley, Tom Taylor, 2014-04-09, 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. "A Virtualized Network Element Framework", Kenji Kumaki, Prodosh Mohapatra, David Meyer, Kannan Varadhan, Zafar Ali, 2014-01-11, This document outlines a new architectural paradigm of virtualizing the service provider networks and its associated engineering requirements. The framework is referred to as the virtual network element framework (VNEF) in the document. "Differentiated Service Class Recommendations for LLN Traffic", Shitanshu Shah, Pascal Thubert, 2014-02-12, 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. "Mutually Exclusive Link Group (MELG)", Vishnu Beeram, Igor Bryskin, 2014-02-12, This document introduces the concept of MELG ("Mutually Exclusive Link Group") and discusses its usage in the context of mutually exclusive Virtual TE Links. "Routing Extensions for Discovery of Role-based MPLS Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership", Zhenbin Li, Mach Chen, Greg Mirsky, 2014-06-17, 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 (OSPF and IS-IS) extensions for discovery Multiprotocol Label Switching (MPLS) LSR TE mesh membership has been defined to automate the creation of mesh of TE LSPs. This document introduces a role-based TE mesh-group that applies to the scenarios where full mesh TE LSPs is 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. "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli, 2014-02-12, 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 RTP mixer is designed to handle RTP splicing in [RFC6828], but how the RTP mixer knows when to start and end the splicing is still unspecified. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the RTP mixer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with stateful PCE", Dhruv Dhody, Udayasree Palle, 2014-01-21, 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 described in [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 automatic bandwidth adjustment of such LSPs under the Active Stateful PCE model. "RADIUS Extensions for Key Management in WLAN network", Li Xue, Dacheng Zhang, Bo Gao, 2014-02-12, When a mobile device (referred to as Station (STA) in this work) tries to connect to a Wireless Local Area Network (WLAN), it needs to first perform mutual authentication with the EAP server of the network. As a result of successful authentication, a Pairwise Master Key (PMK) will be generated, and distributed to the STA and the Authenticator of the network by the EAP server respectively. The PMK is used for securing the subsequent communications between the STA and the Wireless Termination Point (WTP) it attaches to. In practice, the authenticator may not be deployed on the WTP. In this case, an approach is required to help the WTP to obtain the PMK. This work tries to discuss the issues related with this topic and proposes a RADIUS extension to address the problem. "Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE", Yosuke Tanaka, Yuji Kamite, Dhruv Dhody, 2014-02-13, Stateful Path Computation Element (PCE) and its corresponding protocol extensions provide a mechanism that enables PCE to do stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP). Stateful PCE supports manipulating of the existing LSP's state and attributes (e.g., bandwidth and path) via delegation and also instantiation of new LSPs in the network via PCE Initiation. In the current MPLS TE network using Resource ReSerVation Protocol (RSVP-TE), LSPs are often controlled by Make-before-break (M-B-B) signaling by the headend for the purpose of LSP restoration and reoptimization. In most cases, it is an essential operation to reroute LSP traffic without any data disruption. This document specifies the procedure of applying stateful PCE's control to make-before-break RSVP-TE signaling. In this document, two types of restoration/reoptimization procedures are defined, implicit mode and explicit mode. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages, expected behavior of PCC as RSVP-TE headend and necessary extensions of additional PCEP objects. "Simple VPN solution using Multi-point Security Association", Arifumi Yamaya, Ken Ueki, Tomoki Murai, Takafumi Ohya, Tomohiro Yamagata, 2014-01-30, 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, Luca De Cicco, Saverio Mascolo, Harald Alvestrand, 2014-02-14, This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that WG is rmcat@ietf.org. "IEEE 802.21 Overview", Juan-Carlos Zúñiga, Pierrick Seite, 2014-02-14, Some of the messages defined by a potential MIF API may rely on functionalities provided by lower layers. The IEEE 802.21 specification defines an abstraction of lower layer functions that can be useful for a MIF API. This document provides an overview of the IEEE 802.21 specification and enumerates a subset of functions that can be used in the context of the MIF API to interact with lower layers. "Opportunistic Linked-Increases Congestion Control Algorithm for MPTCP", Ramin Khalili, Nicolas Gast, Miroslav Popovic, Jean-Yves Le Boudec, 2014-02-14, This document describes the mechanism of OLIA, the "Opportunistic Linked Increases Algorithm". OLIA is a congestion control algorithm for MPTCP. The current congestion control algorithm of MPTCP, LIA [4], forces a tradeoff between optimal congestion balancing and responsiveness. OLIA's design departs from this tradeoff and provide these properties simultaneously. Hence, it solves the identified performance problems with LIA while retaining non-flappiness and responsiveness behavior of LIA, as shown by different studies [5, 6, 7, 8]. OLIA is now part of the UCLouvain's MPTCP implementation [9]. "Network Proxy Protocol", Sangjin Jeong, 2014-02-14, In the current Internet, it is implicitly assumed that a network node is always active so that it can receive the incoming packets at any time. Current networking services and applications are commonly designed to be fully available at all times with minimal response times. This assumption keeps network nodes from entering sleeping mode in order to reduce energy consumption. Further, during sleeping mode, network nodes may not immediately respond to the incoming packets or even lose them. If network nodes are allowed to go into a sleeping mode, they can effectively reduce energy consumption during idle period. Network proxy allows to delegate network node's traffic processing to an external system within a network, so that the nodes maintain network presence during their sleep. This document describes communication mechanism between network nodes and proxy in order to accelerate the wider deployment of network proxy mechanism. "CoAP Communication with Alternative Transports", Bill Silverajan, Teemu Savolainen, 2014-02-14, CoAP is being 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 understanding how CoAP can operate with other transports, such as the need for M2M communication using non-IP networks, improved transport level end-to- end reliability and security, NAT and firewall traversal issues, and mechanisms possibly incurring a lower overhead to CoAP/HTTP translation gateways. This draft examines the requirements for conveying CoAP packets to end points over such alternative transports. It also provides URI solutions for representing CoAP resources over alternative transports. "UNI Extensions for Diversity and Latency Support", Don Fedyk, Dieter Beller, Lieven Levrau, Daniele Ceccarelli, Fatai Zhang, Yuji Tochio, Xihua Fu, 2014-02-14, This document builds on the GMPLS overlay model [RFC4208] and defines extensions to the GMPLS User-Network Interface (UNI) to support route diversity within the core network for sets of LSPs initiated by edge nodes. A particular example where route diversity within the core network is desired, are dual-homed edge nodes. The core network is typically composed of multiple network domains and those multi-domain diversity aspects that have an implication on the GMPLS UNI extensions are discussed. The document also defines GMPLS UNI extensions to deal with latency requirements for edge node initiated LSPs. This document uses a VPN model that is based on the same premise as L1VPN framework [RFC4847] but may also be applied to other technologies. The extensions are applicable both to VPN and non VPN environments. These extensions move the UNI from basic connectivity to enhanced mode connectivity by including additional constraints while minimizing the exchange of CE to PE information. These extensions are applicable to the overlay extension service model. Route Diversity for customer LSPs are a common requirement applicable to L1VPNs. The UNI mechanisms described in this document are L1VPN compatible and can be applied to achieve diversity for sets of customer LSPs. The UNI extensions in support of latency constraints can also be applied to the extended overlay service model in order for the customer LSPs to meet certain latency requirements. "ICN Management Considerations", Daniel Corujo, Kostas Pentikousis, Ivan Vidal, Jaime Garcia-Reinoso, Stefan Lederer, Spiros Spirou, cedric.westphal@huawei.com, 2014-03-03, Motivated by the need to find and evaluate better ways for reaching on-line content in upcoming Future Internet environments, ICN has been increasingly deployed in an broad range of research and experimental actions. Some deployments even go as far as subjecting ICN to new scenarios beyond content-reaching, exposing the flexibility of ICN core primitives in supporting such mechanisms. In this sense, besides analyzing and discussing the role of network management procedures in ICN environments, this document also analyzes possibilities on how intrinsic core ICN mechanisms can be reutilized for network management. We consider that the availability of management mechanisms for ICN will foster their deployment and, as such, should be tackled still in the design and experimentation phases. Perhaps ICN can adapt successful mechanisms from the host- centric paradigm, or new network management schemes can be designed. Perhaps even both. This document centralizes that discussion, drawing the attention of the ICNRG community to this underdeveloped area of research in ICN. "SCIM Profile For Enhancing Just-In-Time Provisioning", Mark Wahl, 2014-05-07, This document specifies a profile of the System for Cross-Domain Identity Management Protocol (SCIM). Servers which implement protocols such as SAML or OpenID Connect receive user identities through those protocols and often cache them, and this profile of SCIM defines how an identity provider can notify a SCIM server of changes to user accounts. "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Adrian Farrel, John Drake, Nabil Bitar, George Swallow, Daniele Ceccarelli, Xian Zhang, 2014-03-03, 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. The availability of TE information is usually limited to within a network (such as an IGP area) often referred to as a domain. 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. "Virtual Machine Mobility Protocol Using Distributed Registrations", Behcet Sarikaya, Linda Dunbar, Bhumip Khasnabish, 2014-05-14, This document specifies a new IP level protocol for seamless virtual machine mobility in data centers. Source hypervisor registers the newly created virtual machine with the centrally available management node. When the virtual machine moves to the destination hypervisor, the destination hypervisor updates the virtual machine record in the management node. Management node sends registration message to all previous source hypervisors in order to direct the ongoing traffic to the destination hypervisor. Hot, warm and and cold virtual machine mobility are achieved using dynamic domain name system update and host routes. Both intra data center and inter data center hot virtual machine mobility solutions are presented. The requirements for warm and cold mobility of virtual machines are expected to be less stringent than those for the hot mobility option. A short discussion on virtual machine lifecycle management is also included in this draft. "Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) using Interface to Routing System", Susan Hares, Mach Chen, 2014-02-13, Software Defined Networks (SDN) provides a way to virtualize and abstract the network and present the virtual or abstract resources to third-party applications running in software. Applications can utilize a programmable interface to receive these virtual or abstract resources descriptions in a form that allows monitoring or manipulation of resources within the network. The Interface to the Routing System (I2RS) provides an interface directly to the routing System to monitor best paths to any destination or change routes in the routing information base (RIB) or MPLS Label Information Base (LIB). The I2RS interfaces may be combined with other interfaces to the forwarding plane (ForCES (RFC3746)), device configuration (NETCONF), or mid-level/peer-to-peer (ALTO, draft-ietf-alto-protocol) system to create these virtual pathways. This document outlines how SDN networks can use the I2RS interface to implement an automated set of network services for the Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). These systems provide service routing a better way to create paths within a hub and spoke environment, and provide service routing the ability to create pathways based on service. "Protocol Independent Use Cases for an Interface to the Routing System", Russ White, Susan Hares, Alvaro Retana, 2014-06-12, Programmatic interfaces to provide control over individual forwarding devices in a network promise to reduce operational costs while improving scaling, control, and visibility into the operation of large scale networks. To this end, several programmatic interfaces have been proposed. OpenFlow, for instance, provides a mechanism to replace the dynamic control plane processes on individual forwarding devices throughout a network with off box processes that interact with the forwarding tables on each device. Another example is NETCONF, which provides a fast and flexible mechanism to interact with device configuration and policy. There is, however, no proposal which provides an interface to all aspects of the routing system as a system. Such a system would not interact with the forwarding system on individual devices, but rather with the control plane processes already used to discover the best path to any given destination through the network, as well as interact with the routing information base (RIB), which feeds the forwarding table the information needed to actually switch traffic at a local level. This document describes a set of use cases such a system could fulfill. It is designed to provide underlying support for the framework, policy, and other drafts describing the Interface to the Routing System (I2RS). "Extensions to OSPF facilitating the deployment of non-backward- compatible changes.", Mike Dubrovsky, Rashmi Shrivastava, Dean Cheng, 2014-04-18, This document specifies a generic mechanism that facilitates the deployment of non-backward-compatible changes in OSPF protocol. This mechanism allows the OSPF routers to advertise the capability of non- backward-compatible functionality and to make the functionality operational only when supported by all participating routers. Depending on the functionality scope, capability advertisements must be propagated across a link, area or autonomous system (AS). For link and area scope functionality, Router Information Link State Advertisement (LSA) is utilized to propagate the capability information. For the cases when compatibility must be maintained across the whole OSPF autonomous system, new Area Information (AI) LSA is introduced. The AI LSA is a TLV-based analog of Indication- LSA that is used for demand circuit functionality and described in RFC1793. "VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, Samir Thoria, Tapraj Singh, John Drake, 2014-02-14, 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. "IP Inter-Subnet Forwarding in EVPN", Ali Sajassi, Samer Salam, Samir Thoria, Yakov Rekhter, John Drake, Lucy Yong, Linda Dunbar, 2014-02-14, EVPN provides an extensible and flexible multi-homing VPN solution for intra-subnet connectivity among hosts/VMs over an MPLS/IP network. However, there are scenarios in which inter-subnet forwarding among hosts/VMs across different IP subnets is required, while maintaining the multi-homing capabilities of EVPN. This document describes an IRB solution based on EVPN to address such requirements. "A Network Virtualization Overlay Solution using EVPN", Ali Sajassi, John Drake, Nabil Bitar, Aldrin Isaac, Jim Uttaro, Wim Henderickx, 2014-06-19, This document describes how EVPN can be used as an 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: MPLS over GRE, VXLAN, and NVGRE. "Network Performance Isolation using Congestion Policing", Bob Briscoe, 2014-02-14, This document describes why policing using congestion information can isolate users from network performance degradation due to each other's usage, but without losing the multiplexing benefits of a LAN- style network where anyone can use any amount of any resource. Extensive numerical examples and diagrams are given. The document is agnostic to how the congestion information reaches the policer. The congestion exposure (ConEX) protocol is recommended, but other tunnel feedback mechanisms have been proposed. "RSVP-TE Signaling Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Greg Mirsky, Himanshu Shah, Alessandro D'Alessandro, 2014-04-28, Packet switching network MAY contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such link is sensitive to external environment. Availability is typically used for describing the link during network planning. This document describes an extension for RSVP-TE signaling for setting up a label switching path (LSP) in a Packet Switched Network (PSN) network which contains links with discretely variable bandwidth by introducing an OPTIONAL availability field in RSVP-TE signaling. "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. "Enhanced Interior Gateway Routing Protocol", Donnie, Donald Slice, James Ng, Steven Moore, Russ White, 2014-04-11, This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called DUAL, a Diffusing UPDATE Algorithm[4]. The algorithm and procedures were researched, developed, and simulated by SRI International. Savage, et al. Expires October 10, 2014 [Page 1] "Benchmarking Neighbor Discovery", William Cerveny, Ron Bonica, 2014-02-14, 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, 2014-03-11, 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. "RTCWEB Considerations for NATs, Firewalls and HTTP proxies", Thomas Stach, Andrew Hutton, Justin Uberti, 2014-01-20, This document describes mechanism to enable media stream establishment for Real-Time Communication in WEB-browsers (WebRTC) in the presence of network address translators, firewalls and HTTP proxies. HTTP proxy and firewall deployed in many private network domains introduce obstacles to the successful establishment of media stream via WebRTC. This document examines some of these deployment scenarios and specifies requirements on WebRTC enabled web browsers designed to provide the best possible chance of media connectivity between WebRTC peers. "I2RS overlay use case", fangwei hu, Bhumip Khasnabish, Chunming Wu, 2014-01-27, This document proposes an overlay network use case. The forwarding routers network is an overlay structure. There are two kinds 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. It focus on the encapsulation data forwarding. In order to reduce the equipment cost of Edge Routers, the network virtualization is provided in this document. "Augmented Password-Authenticated Key Exchange for Transport Layer Security (TLS)", SeongHan Shin, Kazukuni Kobara, 2014-02-04, 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. "mLDP extensions for integrating EVPN and multicast", David Allan, Jeff Tantsura, 2014-01-14, This document describes how mLDP FECs can be encoded to support both service specific and shared multicast trees and describes the associated procedures for EVPN PEs. Thus, mLDP can implement multicast for EVPN. "KARP IS-IS security analysis", Uma Chunduri, Albert Tian, Wenhu Lu, 2014-02-04, 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. "pNFS Metadata Striping", Matt Benjamin, Casey Bodley, Adam Emerson, Pranoop Ersani, Peter Honeyman, 2014-01-13, This Internet-Draft describes a means to add metadata striping to pNFS. The text of this draft is substantially based on prior drafts by Eisler, M., with some departures. The current draft attempts to define a somewhat lighter-weight protocol, in particular, seeks to permit striping for "filehandle only" operations such as LOCK and OPEN + CLAIM_FH, without clients having to obtain metadata layouts on regular files. We gratefully acknowledge the primary contributions of Mike Eisler, Pranoop Ersani, and others. Internet Draft Comments Comments regarding this draft are solicited. "LISP Based FlowMapping for Scaling NFV", sbarkai@gmail.com, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, 2014-02-12, 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. "Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide", Manav Bhatia, Dacheng Zhang, Mahesh Jethanandani, 2014-06-26, This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of KARP Design Guidelines [RFC6518]. "TMCH functional specifications", Gustavo Lozano, 2014-05-08, This document describes the requirements, the architecture and the interfaces between the Trademark Clearing House (TMCH) and Domain Name Registries as well as between the TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. "ISSU Benchmarking Methodology", Sarah Banks, Fer, Gery Czirjak, Ramdas Machat, 2014-04-08, Modern forwarding devices attempt to minimize any control and data plane disruptions while performing planned software changes, by implementing a technique commonly known as an 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. "XML Schemas for Reverse DNS Management", Terry Manderson, 2013-03-19, 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-02-10, NAT devices are required to log events like creation and deletion of translations and information about the resources it is managing. The logs are required 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 behave differently and hence it is difficult to expect a consistent behavior. 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. "X.509v3 TLS Feature Extension", Phillip Hallam-Baker, 2014-06-11, 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. "Why Reactive Protocols are Ill-Suited for LLNs", Joydeep Tripathi, Jau, C. Chauvenet, JP Vasseur, 2014-01-06, This document describes serious issues and shortcomings regarding the use of reactive routing protocols in low power and lossy networks (LLNs). Routing requirements for various LLN deployments are discussed in order to judge how reactive routing may or may not adhere to the necessary criteria. "Profile Support for the Atom Syndication Format", Erik Wilde, 2014-01-22, The Atom syndication format is a generic XML format for representing collections. Profiles are one way how Atom feeds can indicate that they support specific extensions. To make this support visible on the media type level, this specification adds an optional "profile" media type parameter to the Atom media type. This allows profiles to become visible at the media type level, so that servers as well as clients can indicate support for specific Atom profiles in conversations, for example when communicating via HTTP. This specification updates RFC 4287 by adding the "profile" media type parameter to the application/atom+xml media type registration. "Domain-based Message Authentication, Reporting and Conformance (DMARC)", Murray Kucherawy, Elizabeth Zwicky, 2014-04-02, This memo presents a proposal for a scalable mechanism by which a mail sending organization can express, using the Domain Name System, domain-level policies and preferences for message validation, disposition, and reporting, and a mail receiving organization can use those policies and preferences to improve mail handling. The email ecosystem currently lacks a cohesive mechanism through which email senders and receivers can make use of multiple authentication protocols to establish reliable domain identifiers, communicate policies about those identifiers, and report about mail using those identifiers. This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. The enclosed proposal is not intended to introduce mechanisms that provide elevated delivery privilege of authenticated email. The proposal presents a mechanism for policy distribution that enables a continuum of increasingly strict handling of messages that fail multiple authentication checks, from no action, through altered delivery, up to message rejection. "Home Documents for HTTP Services: XML Syntax", Erik Wilde, 2014-02-12, The current draft for HTTP Home Documents provides a JSON syntax only. This draft provides an XML syntax for the same underlying data model, so that the concept of HTTP Home Documents can be consistently exposed in both JSON- and XML-based HTTP services. Note to Readers Please discuss this draft on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. "ICANN Registry Interfaces", Gustavo Lozano, 2014-02-10, 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. "HTTP Session Management", Phillip Hallam-Baker, 2014-01-21, The HTTP Session Management Mechanism provides a mean of securely establishing a persistent authentication session between a HTTP client and server that does not rely on the presentation of a confidential bearer token. The Session Management Mechanism is intended to provide a replacement for the existing HTTP State Management Mechanism (Cookies) for this purpose. This document defines the HTTP Accept-Session, Set-Session and Session headers and specifies their use to establish symmetric authentication keys and their use to authenticate and verify specific parts of an HTTP message. Other means by which keys used to authenticate the messages are established are outside the scope of this document. "Non-Gregorian Recurrence Rules in iCalendar", Cyrus Daboo, Gregory Yakushev, 2014-06-11, This document defines how non-Gregorian recurrence rules can be specified in iCalendar data. "TRILL Distributed Layer 3 Gateway Framework", Hao Weiguo, Li Yizhou, Donald Eastlake, Liang Xia, 2014-06-09, Currently TRILL protocol can only provide optimal pair-wise data frame forwarding for layer 2 intra-subnet traffic, not for layer 3 inter-subnet traffic. Normally centralized gateway solution is used for layer 3 inter-subnet traffic forwarding. Centralized gateway solution has following issues: "Implementation Experience of Identifier-Locator Network Protocol for IPv6 (ILNPv6)", Jun Bi, You Wang, Kai Gao, 2014-05-04, 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, 2014-05-08, 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. "An Interoperable Subset of Characters for Internationalized Usernames", Peter Saint-Andre, 2014-04-01, Various Internet protocols define constructs for usernames, i.e., the localpart of an address such as "localpart@example.com". This document describes a subset of Unicode characters to allow in internationalized usernames for the sake of maximal interoperability across Internet protocols. "Service Connection Service (SXS)", Phillip Hallam-Baker, 2014-05-19, Service Connection Service (SXS) is a JSON/REST Web Service that may be used to establish and maintain a 'connection binding' of a device to an account held with a Web Service Provider. Multiple connection bindings may be established under the same account to support multiple devices and/or multiple users of a single device. A connection binding permits a device to securely connect to one or more services offered by the Web Service Provider with support for protocol and protocol version agilty and fault tollerance. The protocol is presented as a HTTP/JSON Web Service and uses the HTTP session continuation mechanism for authentication of transaction messages and supports negotiation of a HTTP session continuation mechanism context for the established endpoint connections. "A Common Operational Problem in DNS Servers - Failure To Respond.", Mark Andrews, 2014-05-13, 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. "VxLAN Router Alert Option", Kanwar Singh, Pradeep Jain, Florin Balus, Wim Henderickx, 2014-03-03, This proposal describes a new option to achieve a mechanism which alerts VxLAN terminating VTEP to more closely examine the contents of the packet encapsulated under VxLAN header. This option is useful for case(s) where a given frame encapsulated within a given VXLAN segment responsible for carrying data between two different End Systems contains some control information (e.g OAM information) that may require special handling/processing by terminating VTEP. "PCP Extension for Third Party Authorization", Dan Wing, Tirumaleswar Reddy, Prashanth Patil, Reinaldo Penno, 2014-04-02, It is often desirable for an application server to permit a flow across a firewall, as happens today when a firewall includes an Application Layer Gateway (ALG) function. However, an ALG has several weaknesses. This document describes a cryptographic technique for an application server to permit a flow across a firewall. This technique uses OAuth and a new PCP option. "Using UDP Checksum Trailers in the Network Time Protocol (NTP)", Tal Mizrahi, 2014-04-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. "A Fragmentation Strategy for Generic Routing Encapsulation (GRE)", Ron Bonica, Carlos Pignataro, Joseph Touch, 2014-02-14, This memo specifies a default GRE tunnel fragmentation strategy, which has been implemented by many vendors and widely deployed on the Internet. This memo also specifies requirements for GRE implementations. Having satisfied these requirements, a GRE implementation will execute the default GRE tunnel fragmentation strategy, specified herein, with minimal configuration. However, with additional configuration, the GRE implementation can execute any of the tunnel fragmentation strategies defined in RFC 4459. "Connectivity Provisioning Negotiation Protocol (CPNP)", Mohamed Boucadair, Christian Jacquenet, 2014-04-23, This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used to facilitate the dynamic negotiation of service parameters between a Customer and a Provider. 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, CDN (Content Delivery Networks) footprint, etc. CPNP can be extended with new Information Elements. "IPv6 Performance and Diagnostic Metrics Destination Option", Nalini Elkins, Keven Haining, Michael Ackermann, 2014-01-27, To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. The base metrics are: packet sequence number and packet timestamp. Metrics derived from these will be described separately. This document solves these problems with a new destination option, the Performance and Diagnostic Metrics destination option (PDM). "SA46T Prefix Resolution (SA46T-PR)", Naoki Matsuhira, 2014-01-07, 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, 2014-01-07, 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. "NSA's Cryptographic Message Syntax (CMS) Key Management Attributes", Paul Timmel, Russ Housley, Sean Turner, 2014-04-30, This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. "Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations", Carl Klatsky, oej, Rifaat Shekh-Yusef, Andrew Hutton, Gonzalo Salgueiro, 2014-04-07, This document captures potential impacts to IPv4 SIP implementations when interworking with IPv6 SIP implementations. Although some amount of interworking translation will occur at the network and application layers, an IPv4 SIP application may still encounter a SIP message with some IPv6 values in it, resulting in unforeseen error conditions. Such potential scenarios will be identified in this document so that SIP application developers can define solutions to handle these cases. Note, this document is not intended to be an exhaustive list, rather to provide an overview of some of the more commonly encountered potential scenarios. "Side effect of DNSSEC: an increase of DS queries", Kazunori Fujiwara, 2014-01-20, An increase of periodic DS queries is observed at top level domain (TLD) DNS servers. The reason of the increase is low NCACHE TTL value and DS nonexistence. This memo presents issues with DNSSEC and small NCACHE TTL value, including possible countermeasures in order to prepare future increase of DS queries. "Seamless Bidirectional Forwarding Detection (S-BFD)", Nobo Akiya, Carlos Pignataro, David Ward, Manav Bhatia, Juniper Networks, 2014-04-17, 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. "Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR)", Nobo Akiya, Carlos Pignataro, Nagendra Kumar, 2014-06-07, Note: this document needs to be updated to align with changes in the S-BFD base document. This specification defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) in a Segment Routing (SR) based environment. "Seamless Bidirectional Forwarding Detection (BFD) for IP", Nobo Akiya, Carlos Pignataro, David Ward, 2014-06-07, Note: this document needs to be updated to align with changes in the S-BFD base document. This specification defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) in IP and IP signalled MPLS environments. "Harmonizing how applications specify DANE-like usage", Olafur Gudmundsson, 2014-02-14, There is no standard terminology as how to talk about use of DNS in various application contexts, this document goal is to facilitate creation of such a vocabulary/taxonomy. This document started out as proposal for specific word usage for specifications of adding DANE like technology by different protocols/ services. DANE is a method for specifying in DNS records acceptable keys/certificates for application servers. The terms defined in this document should be applicable to all uses of service specification that uses DNS records. "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Phillip Hallam-Baker, 2014-01-21, 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, 2014-05-16, 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, 2014-06-16, 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. "A method for mitigating namespace collisions", Warren Kumari, 2013-11-22, This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict. "Packet Sequence Number based directional airtime metric for OLSRv2", Henning Rogge, Emmanuel Baccelli, 2014-02-14, This document specifies an directional airtime link metric for usage in OLSRv2. "Interface Selection Mechanism for Multiple Interfaces IPv6 Hosts", Arnaud Kaiser, Alex Petrescu, 2014-01-06, This document describes an interface selection mechanism that enables multiple interfaces (multihomed) IPv6 hosts to select their most appropriate egress interface to send data over the network. The mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with two new Router Advertisement options. "The 'file' URI Scheme", Matthew Kerwin, 2014-03-06, This document specifies the file Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to keep the information about the scheme on standards track, since RFC 1738 has been made obsolete, and to promote interoperability by addressing disagreements between various implementations. Note to Readers This draft should be discussed on its github project page [github]. "PCP for SIP Deployments in Managed Networks", Mohamed Boucadair, 2014-04-16, This document discusses how PCP (Port Control Protocol) can be used in SIP deployments in managed networks. "BGP vector routing.", Keyur Patel, Robert Raszuk, Burjiz Pithawala, Ali Sajassi, Luay Jalil, Jim Uttaro, 2014-04-21, 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. "Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Florin Balus, Keyur Patel, Ali Sajassi, 2014-06-19, This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [EVPN], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. "CoAp Management Interfaces", Peter Van der Stok, Bert Greevenbosch, 2014-05-08, The draft describes an interface based on CoAP to manage constrained devices via MIBs. The proposed integration of CoAP with SNMP reduces the code- and application development complexity by accessing MIBs via a standard CoAP server. The payload of the MIB request is CBOR based on JSON. The mapping from SMI to CBOR is specified. The introduction motivates the choices of CoMI with respect to utilization of YANG, NETCONF, SMI, CBOR, CoAP, and URI structure. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "OSPF Extensions for Segment Routing", Peter Psenak, Stefano Previdi, Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff Tantsura, 2014-06-05, 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 OSPF extensions that need to be introduced for Segment Routing. "The Session Description Protocol (SDP) Application Token Attribute", Roni Even, Jonathan Lennox, Qin Wu, 2014-04-11, The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how to de-multiplex streams within an RTP session, but in some use cases applications need further identifiers in order to identify the signaling descriptions associated with particular RTP media streams. This document defines a mechanism to provide the mapping between the SSRCs of RTP streams and the SDP m-line description by defining extensions to RTP and RTCP messages. "Network Configuration Negotiation Problem Statement and Requirements", Sheng Jiang, Yuanbin Yin, Brian Carpenter, 2014-05-19, This document describes a problem statement and general requirements for distributed autonomic configuration of multiple aspects of networks, in particular carrier networks. The basic model is that network elements need to negotiate configuration settings with each other to meet overall goals. The document describes a generic negotiation behavior model. The document also reviews whether existing management and configuration protocols may be suitable for autonomic networks. "Information Elements for IPFIX Metering Process Location", Olivier Festor, Abdelkader Lahmadi, Rick Hofstede, Aiko Pras, 2014-01-14, This document defines a set of Information Elements for the IP Flow Information Export (IPFIX) protocol for exporting location information of any device (both fixed and mobile) that acts as an IPFIX Flow Exporter. The specified Information Elements support both geospatial and civic location data. "Extension Mechanism for the Babel Routing Protocol", Juliusz Chroboczek, 2013-06-30, This document defines the encoding of extensions to the Babel routing protocol [BABEL]. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda, Tatsuya Hayashi, Yuichi Ioku, 2014-04-24, This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). "CoAP Implementation Guidance", Matthias Kovatsch, Olaf Bergmann, Esko Dijk, Xuan He, Carsten Bormann, 2014-03-03, The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks, e.g., sensor nodes in a low-power lossy network (LLN). Yet to implement this Internet protocol on Class 1 devices (i.e., ~ 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 [I-D.ietf-core-coap], memory optimizations, and customized protocol parameters. "Multicast Support for Mapping of Address and Port Protocol", Behcet Sarikaya, 2014-02-05, This memo specifies MAP-E's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In the encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP-E Border Relay so that MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge device. In the Translation Multicast solution for the translation variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. MAP-T/4rd Border Relay does the reverse translation and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. "Support for Icalendar Relationships", Mike Douglass, 2014-01-07, This specification updates RELATED-TO and introduces new iCalendar properties LINK and RELATED-ID to allow better linking and grouping of iCalendar components and related data. "Efficient Chunk Availability Compression for PPSP", Deng Lingli, Jin Peng, Yunfei Zhang, Rachel Huang, 2014-02-13, Bloom filters are proposed to be used in compressing chunk availability information, periodically exchanged between peers and the tracker through PPSP-TP and PPSPP protocols, to reduce relevant cost and enhance scalability. "Energy Aware Control Approach for QoS in heterogeneous packet access networks", DH, Nico Bayer, Christoph Lange, 2014-01-17, 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, 2014-02-13, 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 router. A basic model for measuring tunnel congestion and congestion information feeding back is described, and a protocol for congestion information feeding back is outlined. "Draft and Release using Internet Email", Alexey Melnikov, 2014-05-19, 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. "On Demand Mobility Management", Alper Yegin, Kisuk Kweon, Jinsung Lee, Jungshin Park, 2013-12-24, 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. "Considerations for ALTO with network-deployed P2P caches", Deng Lingli, Wei Chen, Qiuchao Yi, Yan Zhang, 2014-02-13, Uploading from peers located in a public WLAN hotspot has been reported to severely impact other current users' experiences, and raised caution from the operator's side who are willing to increasingly participate in building public WLAN facilities to offload the explosive mobile data traffic from cellular networks. Cooperation between the network operator and the P2P service providers in form of intra-domain P2P caches is expected to be an effective mechanism to solve the problem. This draft introduces considerations on ALTO deployment in terms of P2P caches and discusses potential extensions to the ALTO protocol to standardize this mutual cooperation. "DTLS-based Security with two-way Authentication for IoT", Corinna Schmitt, Burkhard Stiller, 2014-02-11, In this draft the first key idea for a full two-way authentication security scheme for the Internet of Things (IoT) based on existing Internet standards, specifically the Datagram Transport Layer Security (DTLS) protocol, is introduced. 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 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 would be to use elliptic curve cryptography. For sure the proposed handshake will stay the same. "Use cases for operating networks in the overlay model context", Daniele Ceccarelli, Oscar de Dios, Fatai Zhang, Xian Zhang, Zafar Ali, Rajan Rao, Sergio Belotti, 2014-03-05, This document defines a set of use cases for operating networks in the overlay model context through the Generalized Multiprotocol Label Switching (GMPLS) overlay interfaces. "Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator and BFD Path Tracing", Nobo Akiya, Carlos Pignataro, David Ward, 2014-01-03, This specification defines a concept of alert discriminator which operates over Seamless Bidirectional Forwarding Detection (S-BFD). New diagnostic codes, solely to be used together with alert discriminators, are also defined in this specification. "Path Computation Element (PCE) Discovery using Domain Name System(DNS)", Wenson Wu, Dhruv Dhody, Daniel King, Diego Lopez, Jeff Tantsura, 2014-05-08, Discovery of the Path Computation Element (PCE) within an IGP area or routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. 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 those proposed in [RFC5088] and [RFC5089]. 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, 2014-01-22, 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. "Access Control Framework for Constrained Environments", Goran Selander, Mohit Sethi, Ludwig Seitz, 2014-02-14, The Constrained Application Protocol (CoAP) is a light-weight web transfer protocol designed to be used in constrained environments. Transport layer security for CoAP has been addressed with a DTLS binding for CoAP. This document describes a generic and dynamic access control framework suitable for constrained devices e.g. using CoAP and DTLS. The framework builds on well known paradigms for access control, externalizing authorization decision making to unconstrained nodes while performing authorization decision enforcement and verification of local conditions in constrained devices. "Asserting DNS Administrative Boundaries Within DNS Zones", Andrew Sullivan, Jeff Hodges, 2014-03-04, 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. The solution offered in this memo is to provide a means to make explicit assertions regarding the administrative relationships between domain names. "Negotiating Human Language in Real-Time Communications", Randy, 2014-02-14, 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 communicate and ideally match (i.e., negotiate) the caller's language preferences 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 plus an optional SIP "hint." "QoS-level aware Transmission Protocol (QTP) for virtual networks", Yuxiang Hu, Guozhen Cheng, Zhiming Wang, Lu Sun, 2014-01-07, This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. "Time Capability in NETCONF", Tal Mizrahi, Yoram Moses, 2014-06-25, 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. "Current issues with existing RBNF notation for PCEP messages and extensions", Ramon Casellas, Cyril Margaria, Adrian Farrel, Oscar de Dios, Dhruv Dhody, Xian Zhang, 2014-01-10, The PCEP protocol has been defined in [RFC5440] and later extended in several RFCs. This document aims at documenting inconsistencies when implementing a set of extensions and at providing a reference, complete and formal RBNF grammar for PCEP messages, including object ordering and precedence rules. "Segment-Based EVPN(S-EVPN)", Zhenbin Li, Lucy Yong, Junlin Zhang, 2014-02-13, This document proposes an enhanced EVPN mechanism, segment-based EVPN (S-EVPN). It satisfies the requirements of PBB-EVPN but does not require PBB implementation on PE. The solution uses a global label for each Ethernet Segment (ES) in an EVPN. It inserts the source ES label into packets at ingress PE and learns C-MAC and source ES label binding at egress PE. The solution makes the implementation easier and closer to E-VPN compared to PBB-EVPN but has the PBB-EVPN benefits. "Radius Extension for Lightweight 4over6", Chongfeng Xie, Qi Sun, Qiong, Cathy Zhou, Tina Tsou, ZiLong Liu, 2014-03-06, lightweight 4over6(lw4over6) [I-D.ietf-softwire-lw4over6] is an extension to DS-Lite in which the amount of state maintained in lwAFTR has been reduced to per-subscriber-level. The lwB4 needs to be provisioned with the public IPv4 address and port set it is allowed to use. The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc- dhcpv4-over-dhcpv6] and Dynamic Host Configuration Protocol (DHCP) Option for Port Set [I.D-sun-dhc-port-set-option] can be used for lwB4 to provison with the public IPv4 address and port set. 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). This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries lightweight 4over6 configuration information from AAA server to BNG. "IS-IS Protocol Extension For Building Distribution Trees", Lucy Yong, Hao Weiguo, Donald Eastlake, Andrew Qu, Jon Hudson, 2014-06-12, This document proposes an IS-IS protocol extension for automatically building bi-directional distribution trees to transport multi- destination traffic in an IP network. "RPKI Validation Reconsidered", Geoff Huston, George Michaelson, 2014-02-09, This document reviews the certificate validation procedure specified in RFC6487 and highlights aspects of operational management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain certification of resources during this movement. The document describes an alternative validation procedure that reduces the operational impact of certificate management during resource movement. "BGP Extensions for Service-Driven Co-Routed MPLS Traffic Engineering LSP", Hui Ni, Shunwan Zhuang, Zhenbin Li, 2014-02-12, In some large scale L3VPN deployment scenarios like mobile backhaul network, it is required that tunnels between two PEs could be setup automatically driven by L3VPN service to reduce manual configuration effort. Moreover the tunnels must be setup co-routed for the goodness of performance monitoring and uniform protection behavior for link failure on two directions. This is described in [I-D.li- mpls-serv-driven-co-lsp-fmwk]. This document introduces a new BGP VT route based on [I-D.ni-bgp-ext-l3vpn-pm]. The route is utilized by on side PE to advertise Tunnel ID to other side PE, so inverse direction co-routed LSPs can be setup based on path information of member LSPs in the first tunnel. "BGP Extension For L3VPN Performance Monitoring", Hui Ni, Shunwan Zhuang, Zhenbin Li, 2014-02-12, This document describes a new VT address family in BGP to exchange information required for apply performance monitoring in MPLS/BGP VPN, as described in [I-D.dong-l3vpn-pm-framework]. "Dynamic Stateless GRE Tunnel", Li Xue, Dayong Guo, 2014-02-14, Generic Routing Encapsulation (GRE) is regarded as a popular encapsulation tunnel technology because of simpleness and easy implementation. When a node tries to encapsulate the user traffic in a GRE tunnel, it needs to first obtain the IP address of some destination node to decapsulate the GRE packets. According to the information of destination node, a node can setup the GRE tunnel connection. In practice, the IP address of decapsulation node of GRE tunnel may be manually configured on the GRE encapsulation side. This configuration introduces efficiency issues for operators, especially, in the scenarios where there are large amount of GRE tunnels needed. This work proposes an approach to configure the GRE tunnel dynamically. "One Administrative Domain", Jim Uttaro, Saikat Ray, Prodosh Mohapatra, 2014-01-09, The notional premise that different Autonomous Systems belong to different administrative authorities may not always hold. A single administrative authority may instantiate services on and across multiple ASes. A customer accessing those services can reasonably expect that attributes such as LOCAL_PREF that influence routing be applicable even across different ASes. This document describes a mechanism to do so. "Use Cases and Architecture of Central Controlled IP RAN", Katherine Zhao, Jiehui Hu, So Ning, 2014-02-13, This document introduces the requirements and use cases for IP RAN (Radio Access Networks). To support the requirements, the document provides an architecture with centralized control plane as well as separation of control plane and data plane. The document also describes techniques for IP RAN network initialization and construction; interfacing to management plane and third party applications. This document can be used as a guideline for central controlled IP RAN design and development. "IPv4 Address Literal in URL", Osamu Nakamura, Hiroaki Hazeyama, Yukito Ueno, Akira Kato, 2014-01-11, In an IPv6-only environment with DNS64/NAT64 based translation service, there is no way to get access a URL whose domain name part includes an IPv4 address literal. This memo discusses a few methods to rewrite the URL on an IPv6-only host so that the URL is accessible from the IPv6-only host. "Securing UDT using TLS/DTLS", Tatikayala Gopal, 2014-01-09, This document describes about providing security to UDP Based Data Transfer (UDT) protocol. UDT is application level protocol built on the top of UDP, which effectively utilizes bandwidth in the high speed network as compared with TCP. UDT relies on the above layer for security because of absence of in-build security mechanisms. This document proposes the use of Transport Layer Security (TLS)/Datagram Transport Layer Security (DTLS) for securing the UDT protocol. "Considerations for Selecting RTCP Extended Report (XR) Metrics for the RTCWEB Statistics API", Rachel Huang, Roni Even, Varun Singh, Dan Romascanu, Deng Lingli, 2014-02-14, This document describes monitoring features related to RTCWEB. It provides a list of RTCP XR metrics that are useful and may need to be supported in some RTCWEB implementations. "Stateless user-plane architecture for virtualized EPC (vEPC)", Satoru Matsushima, Ryuji Wakikawa, 2014-02-13, 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. "Free from Using Zone Identifier for IPv6 Link-Local Address", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 2014-02-14, This document describes "Zone-ID Free" functions that make end users free from using zone identifiers (Zone-ID) for IPv6 link- local addresses. When users deal with IPv6 link-local addresses, it is thought that it is mandatory thing to specify accompanied Zone-IDs. For end users, however, it is troublesome and nuisance thing to do it. Because it is very hard for normal end users to find appropriate Zone-IDs for this purpose. From another viewpoint, the usage of IPv6 link-local addresses accompanied with Zone-IDs is quite different from the traditional usage of global addresses. Therefore many problems related with Zone-ID are caused and new specifications are required to fix these problems. This document explores and describes how "Zone-ID Free" functions work and how end users are released from using Zone-IDs when they deal with IPv6 link-local addresses. The "Zone-ID Free" functions are upper compatible with the current usages of dealing with IPv6 link-local addresses and harmless to the existing communications. In order to obtain appropriate Zone-ID information, a new technology "Zone-ID Learning" that issues multiple probes is introduced. "Usecases of MPLS Global Label", Zhenbin Li, Quintin Zhao, Tianle Yang, 2014-02-13, As the SDN(Service-Driven Network) technology develops, MPLS global label has been proposed again for new solutions. The document proposes possible usecases of MPLS global label. MPLS global label can be used for identification of the location, the service and the network in different application scenarios. From these usecases we can see that no matter SDN or traditional application scenarios, the new solutions based on MPLS global label can gain advantage over the existing solutions to facilitate service provisions. "A Framework of MPLS Global Label", Zhenbin Li, Quintin Zhao, Tianle Yang, 2014-02-14, The document defines the framework of MPLS global label including: representation of MPLS global label, process of control plane for MPLS global label, and process of data plane for MPLS global label. "Efficient XML Interchange Capability for NETCONF", Robert Varga, 2014-03-03, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices via exchange of XML messages in textual representation. Efficient XML Interchange (EXI) is a W3C-recommended binary representation of XML Information Set, which is more efficient from both CPU and bandwidth utilization perspective. This document defines a capability-based extension to the NETCONF protocol that allows peers to agree to exchange protocol messages using EXI encoding. "Energy-awareness metrics global applicability guidelines", Antonio Junior, Rute Sofia, 2014-01-09, This document describes a new set of energy-awareness metrics which have been devised to be applicable to any multihop routing protocol having in mind LLNs, including the Routing for Low Power and Lossy Networks (RPL) protocol. "An IPv6 Distributed Client Mobility Management approach using existing mechanisms", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, 2014-02-03, 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. "The I-JSON Message Format", Tim Bray, 2014-01-06, I-JSON is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. "OSPF Routing Extension for Links with Variable Discrete Bandwidth", Hao Long, Min Ye, Greg Mirsky, Himanshu Shah, 2014-04-26, Packet switching network MAY contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such link MAY change discretely in reaction to changing external environment. Availability is typically used for describing such links during network planning. This document describes an extension for OSPF routing for route computation in a Packet Switched Network (PSN) which contains links with variable discrete bandwidth by introducing an OPTIONAL Availability sub-TLV. "JSON Activity Streams 2.0", James Snell, 2014-05-27, This specification details a model for representing potential and completed activities using the JSON format. "Seamless MPLS for Mobile Backhaul", Zhenbin Li, Lei Li, Manuel Morillo, Tianle Yang, 2014-02-13, This document introduces the framework of Seamless MPLS to integrate the mobile backhaul network with the core network. New requirements of Seamless MPLS for mobile backhaul networks are defined and corresponding solutions are proposed. "Implication of 3GPP Link Characteristics on Lightweight IP Design", Yuanchen Ma, Zehn Cao, 2014-01-27, In 3GPP Release 12, the work item Machine Type Communication (MTC) is specifying low cost terminals for Machine to Machine communications. Since IETF has already developed a suite of protocols for device communication, it is useful to analyze the limitation of 3GPP MTC and the impact on the implementation of IETF protocol suite. This document analyzes the feature of 3GPP MTC and the impact on light weight protocol implementation for the MTC terminals. "CoAP over WebSockets", Teemu Savolainen, Klaus Hartke, Bill Silverajan, 2014-04-10, This document specifies how to retrieve and update CoAP resources using CoAP requests and responses over the WebSocket Protocol. "A Framework for E-VPN Performance Monitoring", Lianshu Zheng, Zhenbin Li, Sam Aldrin, 2014-02-13, The capability of Ethernet VPN performance monitoring (PM) is important to meet the Service Level Agreement(SLA) for the service beared. Since multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge for E-VPN PM. This document specifies the framework and mechanisms for the application of E-VPN PM. "Multicast State Advertisement in E-VPN", Zhenbin Li, Junlin Zhang, 2014-02-13, The document defines a new extended community to advertise the active or inactive state for multicast along with the Inclusive Multicast Ethernet Tag route or Ethernet Auto-Discovery route in E-VPN. The multicast state advertised can help optimization of multicast process in E-VPN to reduce unnecessary traffic replication for the broadcast, unknown unicast and multicast (BUM) traffic. "Alternate Tunnel Encapsulation for Data Frames in CAPWAP", Rong Zhang, Zehn Cao, Hui Deng, Rajesh Pazhyannur, Sri Gundavelli, Li Xue, 2014-03-05, CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC) using CAPWAP. 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 it is desirable to encapsulate date frames to an entity different from the AC for example to an Access Router (AR). 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. "MPLS Domain Wide Labels", Robert Raszuk, 2014-01-02, 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, 2014-02-14, 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. "Analysis of LMP Security According to KARP Design Guide", Mahesh Jethanandani, 2014-02-11, This document analyzes Link Management Protocol (LMP) according to guidelines set forth in section 4.2 of KARP Design Guidelines (RFC 6518). "Virtualized Network Function (VNF) Pool Problem Statement", Ning Zong, Linda Dunbar, Melinda Shore, Diego Lopez, Georgios Karagiannis, 2014-05-05, Network functions are traditionally implemented on specialized hardware rather than on general purpose servers, but there is a clear trend to implement a number of network functions, such as firewall or load balancer, as software on virtualized computing platforms. These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services. The use of VNFs to build network services introduces additional challenges on reliability, such as additional points of failure and the need to coordinate various VNFs. This document introduces a general idea of VNF Pool to support reliable function provision by the VNFs. We then highlight the reliability challenges and issues when using the VNFs to build services. Related IETF works are also briefly described. "Network Mobility Support in the Distributed Mobility Management", xuan@dcn.ssu.ac.kr, Young-Han Kim, 2014-04-21, Network mobility (NEMO) provides session continuity for mobile nodes (MN) while moving in vehicles without their involvement in signaling process. NEMO Basic support protocol [RFC3963] is standardized to provide network mobility support. Current mobility management protocols, such as MIPv6 [RFC6275] and PMIPv6 [RFC5213], rely on a central mobility anchor in order to provide mobility support for the mobile nodes. These centralized approaches show some big issues, such as a single point of failure, non-optimal routing, and scalability. Ever-increasing demand for the mobile traffic changes the network architecture from hierarchical to flat architecture, and distributed mobility management (DMM) approaches are being researched to adapt the new flat architecture and overcome big above issues. This document presents about detailed protocol operation to support network mobility in the DMM domain. "Label Sharing for Fast PE Protection", Mingui Zhang, Peng Zhou, Russ White, 2014-06-17, This document describes a method to be used by VPN Service Providers to provide multi-homed CEs with fast protection of egress PEs. Egress PEs in a redundant group always share the same label in distribution of VPN routes of a VRF. A virtual Next Hop (vNH) in the IGP/MPLS backbone is created as the common end of LSP tunnels which would otherwise terminate at each egress PE. Primary and backup LSP tunnels ended at the vNH are set up by MPLS on basis of existing IGP FRR mechanisms. If the primary egress PE fails, the backup egress PE can recognize the "shared" VPN route label carried by the data packets. Therefore, the failure affected data packets can be smoothly rerouted to the backup PE for delivery without changing their VPN route label. "Use case analysis for supporting flow mobility in DMM", gomjae@dcn.ssu.ac.kr, Young-Han Kim, 2014-04-22, 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) [RFC5213], 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. "Shim Header for CoAP Transfer over non-TCP/IP Networks", Sim-Kwon Yoon, Ilkyun Park, Namhi Kang, Seung-Hun Oh, Byoung-Tak Lee, 2014-02-14, This document defines shim header for the transfer of CoAP messages over non-TCP/IP constrained networks. In this environment, IP and UDP or TCP are not used, so that additional shim header as a container for addresses of sender/receiver and the length of CoAP header and its payload is required. "MultiProtocol Label Switching (MPLS) Source Label", Mach Chen, Xiaohu Xu, Zhenbin Li, Luyuan Fang, Greg Mirsky, 2014-04-15, A MultiProtocol Label Switching (MPLS) label was originally defined to identify a Forwarding Equivalence Class (FEC), a packet is assigned to a specific FEC based on its network layer destination address. It's difficult or even impossible to derive the source identity information from the label. For some applications, source identification is a critical requirement. For example, performance monitoring, where the monitoring node needs to identify where a packet was sent from. This document introduces the concept of Source Label (SL) that is carried in the label stack and used to identify the ingress Label Switching Router (LSR) of an Label Switched Path (LSP). "Authenticating version 3 of the Simple Network Management Protocol (SNMPv3) using HMAC-SHA-2 procedures", Sam Hartman, Margaret Wasserman, Dacheng Zhang, Manav Bhatia, 2014-01-28, This document describes the mechanism to authenticate SNMPv3 protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. "Role-Based State Advertisement for Multicast in MPLS/BGP IP VPNs", Zhenbin Li, Hui Ni, 2014-01-16, The document defines a new type of Intra-AS I-PMSI A-D route to advertise the role and corresponding primary/backup state for Multicast in MPLS/BGP IP VPNs. The role-based state advertisement can help optimization of process in MPLS/BGP Multicast VPN to reduce unnecessary traffic replication and facilitate service provision. "NEXTHOP_PATH ATTIBUTE for BGP", Zhenbin Li, Li Zhang, 2014-01-15, As the BGP is deployed in a single Autonomous System for network convergence such as Seamless MPLS, it is desirable for BGP to carry more information to help select routing more intelligently. It can reduce the cost proposed by complex policy control design on BGP routes and adapt to network change easily. This document proposed a new path attribute for BGP routes that can record the next hop path for the route to help BGP route selection and network management. "RSVP-TE Extensions for Bit Error Rate (BER) Measurement", Zhenbin Li, Li Zhang, 2014-01-15, In the mobile backhaul network, the mobile service is sensitive to Bit Error Rate (BER). When the BER value of the service exceeds the threshold, the Base Station will stop working and the User Equipments (UEs) cannot obtain voice and data services anymore. Now the mobile backhaul tends to be IP/MPLS network and MPLS TE LSP is used to bear the mobile service which may be encapsulated in PW or L3VPN end to end. Then the ingress Label Switched Router (LSR) of the MPLS TE LSP needs to get information on BER along the path of the LSP. This document proposes new extensions of RSVP-TE to advertise the BER measurement requirement of the specific LSP to all of the transit LSRs and the egress LSR, and to report the BER measurement result from any transit or egress LSR towards the ingress LSR. "Detecting NVO3 Overlay Data Plane failures", Nagendra Kumar, Carlos Pignataro, Dhananjaya Rao, Sam Aldrin, 2014-01-14, This document describes a simple and efficient mechanism to perform L2 or L3 VN Context validation and to detect any data plane failures in IPv4 or IPv6 based overlay network providing L2 or L3 virtualized network. "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Fred Baker, 2014-04-21, Home IT staff is generally unfamiliar with network operations, making it desirable to provide a configuration-free mode of operation. Policy-based routing (in the sense of configuring one router to redirect traffic to another based on access control) and multi- topology routing both require configuration, making them undesirable. In this document, we propose a configuration-free mechanism, in which packets will be routed towards the corresponding upstream ISPs based on both destination and source addresses. "Data Center Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Florin Balus, 2014-02-14, This document describes how Network Virtualization Overlay networks (NVO3) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution will analyze the interaction between NVO3 networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB- VPLS or EVPN/PBB-EVPN, and will propose a solution for the interworking between both. "LISP Extensions for Segment Routing", Frank Brockners, Shwetha Bhandari, Fabio Maino, Darrel Lewis, 2014-02-13, Segment Routing (SR) combines source routing and tunneling to steer traffic through the transit network. The Locator/ID Separation Protocol (LISP) separates IP addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) and also leverages tunneling mechanisms. Mapping between EIDs and RLOCs is facilitated by the LISP mapping system. Combining LISP and SR enables the LISP mapping system to provide SR information to encapsulating routers so that traffic can be steered in the transit network or the list of segments a particular packet traverses is recorded in the packet header. This document describes extensions required to the Locator/ID Separation Protocol (LISP) to enable a LISP mapping system to communicate list of segment identifiers or the request to record the list of segments a particular packet traverses to the encapsulating router. "Interface to the Routing System (I2RS) for Service Chaining: Use Cases and Requirements", Nabil Bitar, Giles Heron, Luyuan Fang, ramki, Nicolai Leymann, Himanshu Shah, Wassim Haddad, 2014-02-14, Service chaining is the concept of applying an ordered set of services to a packet or a flow. Services in the chain may include network services such as load-balancing, firewalling, intrusion prevention, and routing among others. Criteria for applying a service chain to a packet or flow can be based on packet/flow attributes that span the OSI layers (e.g., physical port, Ethernet MAC header information, IP header information, transport, and application layer information). This document describes use cases and I2RS (Information to the Rousting System) requirements for the discovery and maintenance of services topology and resources. It also describes use cases and I2RS requirements for controlling the forwarding of a packet/flow along a service chain based on packet/flow attributes. "SDN Layers and Architecture Terminology", Evangelos Haleplidis, Spyros Denazis, Kostas Pentikousis, Jamal Hadi Salim, David Meyer, Odysseas Koufopavlou, 2014-03-03, Software-Defined Networking (SDN) can in general be defined as a new approach for network programmability. Network programmability refers to the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces as opposed to relying on closed-box solutions and propietary-defined interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what is the layer structure in an SDN architecture and how do layers interface with each other. This document aims to answer these questions and provide a concise reference document for SDNRG, in particular, and the SDN community, in general, based on relevant peer-reviewed literature and documents in the RFC series. "Two-Way Active Measurement Protocol (TWAMP) Management Information Base (MIB)", Tamas Elteto, Greg Mirsky, 2014-01-14, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Management Information Base of Two-Way Active Measurement Protocol [RFC5357] for both Control and Test protocols. "Using DANE to Associate OpenPGP public keys with email addresses", Paul Wouters, 2014-02-14, OpenPGP is a message format for email (and file) encryption, that lacks a standarized lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. "Multicast state damping", Thomas Morin, Stephane Litkowski, Keyur Patel, Jeffrey Zhang, Robert Kebler, Jeffrey Haas, 2014-01-14, This document describes procedures to damp multicast routing state changes and prevent the churn due to the multicast dynamicity at the edge of a network. The procedures described in this document help avoid uncontrolled control plane load increase on the core routing infrastructure. New procedures are proposed inspired from BGP unicast route damping principles, but adapted to multicast. They cover multicast and multicast in VPNs contexts. "Private Autonomous System (AS) Removal Requirements", Jon Mitchell, Dhananjaya Rao, Robert Raszuk, 2014-02-12, 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. "Stateful PCE Extensions for Data Plane Switchover and Balancing", Yosuke Tanaka, Yuji Kamite, Ina Minei, Dhruv Dhody, 2014-02-13, Stateful Path Computation Element (PCE) and its corresponding protocol extensions provide a mechanism that enables PCE to do stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP). One application that stateful PCE can realize is data traffic reoptimization among the LSPs. Data traffic traversed in a LSP can be switched to another PCE-initiated LSP. Moreover, data traffic can be balanced to multiple PCE-initiated LSPs and may also be policed based on a signaling bandwidth of a PCE-Initiated LSP using stateful PCE. This document specifies the extensions to Path Computation Element Protocol (PCEP) that allow a stateful PCE to do switchover, balancing and policing of data traffic with PCE-initiated LSPs. This document also specifies the extensions, usage and handling of stateful PCEP messages and the expected behavior of PCC as the RSVP-TE headend. "OSPF Stub Neighbors", Khalid Raza, Jon Cavanaugh, Andrew Kulawiak, Padma Pillay-Esnault, Faraz Shamim, 2013-07-15, Open Shortest Path First stub neighbor is an enhancement to the protocol to support large scale of neighbors in some topologies with improved convergence behavior. It introduces limited changes protocol behavior to implement a scalable solution for hub and spoke topologies by restricting the functionality changes to the hub. The concepts are also applicable to a host running in a virtual machine environment. "Delegated CoAP Authentication and Authorization Framework (DCAF)", Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, 2014-02-14, 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. "Parallel NFS (pNFS) Flexible File Layout", Benny Halevy, Tom Haynes, 2014-06-11, The Parallel Network File System (pNFS) allows a separation between the metadata and data for a file. The metadata file access is handled via Network File System version 4 (NFSv4) minor version 1 (NFSv4.1) and the data file access is specific to the protocol being used between the client and storage device. The client is informed by the metadata server as to which protocol to use via a Layout Type. The Flexible File Layout Type is defined in this document as an extension to NFSv4.1 to allow the use of storage devices which need not be tightly coupled to the metadata server. "A-PAWS: Alternative Approach for PAWS", Yoshifumi Nishida, 2014-06-10, This documents describe a technique called A-PAWS which can provide protection against old duplicates segments like PAWS. While PAWS requires TCP to set timestamp options in all segments in a TCP connection, A-PAWS supports the same feature without using timestamps. A-PAWS is designed to be used complementary with PAWS. TCP needs to use PAWS when it is necessary and activates A-PAWS only when it is safe to use. Without impairing the reliability and the robustness of TCP, A-PAWS can provide more option space to other TCP extensions. "Writing I-Ds using HTML", Phillip Hallam-Baker, 2014-01-21, This memo presents a technique for using as subset HTML as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. The HTML subset provides equivalent functionality to the traditional XML2RFC tool but is designed for ease of use with readily available editing tools. Extensions to the HTML markup allow the use of external bibliography files to manage citations and references in the manner of BibTeX. Planned extensions include building concordances of defined terms and normative language. "The Accept-Post HTTP Header", John Arwe, Steve Speicher, Erik Wilde, 2014-02-06, This specification defines a new HTTP response header field Accept- Post, which indicates server support for specific media types for entity bodies in HTTP POST requests. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. "Providing User Authentication Information to OAuth 2.0 Clients", Phil Hunt, Anthony Nadalin, Michael Jones, 2014-05-28, This specification defines a way for OAuth 2.0 clients to verify the identity of the End-User and obtain consent based upon the authentication performed by an Authorization Server. The interactions defined by this specification are intentionally compatible with the OpenID Connect protocol. "A Framework of Multipath Transport System Based on Application-Level Relay (MPTS-AR)", Lei Weimin, Wei Zhang, Shaowei Liu, 2014-01-22, 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, 2014-01-22, 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, 2014-01-22, 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. "Recommendation for Prefix Binding in the Softwire DS-Lite Context", Suresh Vinapamula, Mohamed Boucadair, 2014-05-06, This document discusses issues induced by the change of the Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues. "CMC (Certificate Management over Cryptographic Message Syntax) Extensions: Server Side Key Generation", Jim Schaad, Sean Turner, Paul Timmel, 2014-03-27, This document defines a set of extensions to the Certificate Management over Cryptographic Message Syntax (CMC) protocol that addresses the desire to support server-side generation of keys for certificates. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. "OAuth Symmetric Proof of Posession for Code Extension", Nat Sakimura, John Bradley, Naveen Agarwal, 2014-04-21, The OAuth 2.0 public client utilizing authorization code grant is susceptible to the code interception attack. This specification describe a mechanism that acts as a control against this threat. "Remote APDU Call Secure (RACS)", Pascal Urien, 2014-01-31, 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. "Handing Over Child SAs Following Re-Authentication in IKEv2", Yoav Nir, 2014-04-13, This document describes an extension to the IKEv2 protocol whereby Child SAs are moved to the new IKE SA following re-authentication. This allows for a smoother transition with no loss of connectivity. "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, 2014-03-11, 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, 2014-03-11, 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, 2014-03-11, 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: Password Policies", Mark Bannister, 2014-03-11, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support the shadow databases. The shadow database schema SHALL be backwards compatible with the Network Information Service [NIS] but stored within [X.500] entries so that it may be resolved with the Lightweight Directory Access Protocol [RFC4510]. A shadow database extends user login accounts with credential policy data. This document represents shadow database entries as an extended set of attributes that may be applied to both passwd and group database entries for the management of consistent password policies. This document describes configuration maps [draft-bannister-dbis- mapping-00] for shadow databases, and database entries referenced by those maps. "Directory-Based Information Services: Hosts, Networks and Services", Mark Bannister, 2014-03-11, 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, 2014-03-11, 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, 2014-03-11, 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. "Directory-Based Information Services: Custom Maps", Mark Bannister, 2014-03-11, This document extends Directory-Based Information Services (DBIS) described in [draft-bannister-dbis-mapping-00] to support custom databases. The custom 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 custom database contains arbitrary key/value pairs. This document describes configuration maps [draft-bannister-dbis- mapping-00] for custom databases, and database entries referenced by those maps. "Marking HTTP Requests as Unimportant", Martin Thomson, 2014-05-14, An HTTP "Nice" header field is defined. "Nice" marks a request as low priority. Gateways can choose to discard or delay the request, or provide a response from cache rather than forwarding it to an origin server. This enables constrained origin servers, such as those that rely on battery power, to avoid expending limited resources on serving requests. "Metadata Query Protocol", Ian Young, 2014-04-22, 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. "Port Control Protocol (PCP) Deployment Models", Mohamed Boucadair, 2014-04-16, This document lists a set of Port Control Protocol (PCP) deployment models. "Prohibiting RC4 Cipher Suites", Andrey Popov, 2014-04-11, This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. "Using ZRTP to Secure WebRTC", Alan Johnston, Philip Zimmermann, Jon Callas, Travis Cross, John Yoakum, 2014-04-03, 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, 2014-04-24, 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, 2014-04-14, 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. "CalDAV: Timezones by Reference", Cyrus Daboo, 2014-03-15, 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 timezone data. "CoAP option for no server-response", Abhijan Bhattacharyya, Soma Bandyopadhyay, Arpan Pal, 2014-06-20, There can be typical M2M scenarios where responses from the data sink to the data source against request from the source might be considered redundant. This kind of open-loop exchange (with no reverse path from the sink to the source) may be desired while updating resources in constrained systems looking for maximized throughput with minimized resource consumption. CoAP already provides a non-confirmable (NON) mode of exchange where The receiving end-point does not respond with ACK. However, the receiving end-point responds the sender with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option: 'No-Response' to suppress responses from the receiver and discusses exemplary use cases which motivated this proposition based on real experience. This option also provides granularity by allowing suppression of a typical class or a combination of classes of responses. This option may be effective for both unicast and multicast scenarios. "Additional Link Relation Registrations", James Snell, 2014-03-12, This specification registers a handful of new RFC 5988 Link Relation types. "An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE", John Klensin, Andrew Sullivan, Patrik Fältström, 2014-03-26, Some protocols use the RDATA field of the DNS TXT RRTYPE for holding data to be parsed, rather than for unstructured free text. This document specifies the creation of an IANA registry for protocol- specific structured data to minimize the risk of conflicting or inconsistent uses of that RRTYPE and data field. "RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen, Rex Fernando, 2014-02-13, This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. "The TCP Service Number Option (SNO)", Joseph Touch, 2014-03-04, 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. "Curve25519 for ephemeral key exchange in Transport Layer Security (TLS)", Simon Josefsson, Manuel Pégourié-Gonnard, 2014-04-13, This document specifies the use of Curve25519 for ephemeral key exchange in the Transport Layer Security (TLS) protocol, as well as its DTLS variant. It updates RFC 5246 (TLS 1.2) and RFC 4492 (Elliptic Curve Cryptography for TLS). "NFS Protocol Extension: Retrospect and Prospect", David Noveck, 2014-03-06, This document surveys the processes by which the NFS protocol has been extended in the past and considers how the mechanisms by which the protocol is extended might best be modified in the future. "IPv6 Path MTU Interactions With Link Adaptation", Fred Templin, 2014-03-10, 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, 2014-03-04, 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. "vCard Format Extensions : phonetic transcription", Teiichiro Fukuda, Taichi Matsuura, Yusuke Yamamoto, 2014-03-25, This specification adds a new property concerning the phonetic transcription to vCard4.0. "Multimedia Conference Recording Use Cases and Requirements", Paul Kyzivat, Michael Yan, Simon Romano, 2014-02-12, The current work of SIPREC will soon finish. As conferences are the key requirement for some environments, it is worth to explore several extensions and additional functionality to support multimedia conference recording. SIPREC is not sufficient to record all the conference sessions via certain interactive media channels, like multi-user chat or screen sharing. This draft tries to show the use cases for multimedia conference recording and the requirements for how to work well under SIPREC mechanism. The requirements ask for extensions to SIP that will manage delivery of RTP media sessions, including content media defined by [RFC4796] , and MSRP media sessions to a recording device. The recorded media sessions are all SIP-based. "IKEv2 based lightweight secure data communication draft-amjads-ipsecme-ikev2-data-channel-01 (D-IKE)", Amjad Inamdar, Rajeshwar Jenwar, 2014-03-12, The Internet Key Exchange (IKEv2) protocol provides authentication, confidentiality, integrity, data-origin authentication and anti- replay. Currently, IKEv2 is mainly used as a control channel to negotiate IPsec SA(s). IPsec is not well suited to provide transport layer security for applications as it resides at the network layer and most of the IPsec implementations require integration into operating systems making it difficult to deploy. IPsec uses different sessions for control and data traffic which is not NAT and load balancer friendly. TLS/DTLS, the other popular security mechanism to provide the above security services does not mandate mutual peer authentication and Diffie Hellman exchange. This document describes an IKEv2 based lightweight secure data communication protocol and a way to provide transport layer security for UDP client/server applications. The protocol provides integrity protected encryption and integrity-only protection based on application needs. As most of the IoT applications are UDP based, IKEv2 can be used for key management as well secure data communication in IoT due to its simplicity, scalability, lightweightedness and ease of deployment. "HTTP Link Descriptions", Erik Wilde, 2014-02-12, Interactions with many resources on the Web are driven by links, and these links often define certain expectations about the interactions (such as HTTP methods being allowed, media types being accepted in the request, or URI templates being supported). While these expectations are essential to define the possible interactions, it may be useful to further narrow them down by providing link descriptions, which can help clients to gain more runtime knowledge about the resource they are about to interact with. This memo defines Link Descriptions, a model and associated media type that can be used to describe links by supporting descriptive markup for representing interaction information with links. Link Descriptions can be used by media types (by inclusion or by reference) that seek to make Link Descriptions runtime-capable, without having to create their own representation for them. "YANG Conformance Specification", Andy Bierman, 2014-06-21, This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. "Using Test Delegations from the Root Prior to Full Allocation and Delegation", Geoff Huston, Olaf Kolkman, Andrew Sullivan, Warren Kumari, 2014-03-08, The delegation of certain strings as generic Top Level Domains (gTLDs) may cause stability and security issues if such strings have been used in private environments prior to their delegation. Test delegations can be used to enable empirical research on the extent of the potential for name collision. This document describes one such approach to an empirical testing framework for name collision, and considers the applicability of this approach to detect other forms of name collision. "PCE support for Domain Diversity", Dhruv Dhody, Qin Wu, Udayasree Palle, Xian Zhang, 2014-03-26, 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). "Data Models for Network Functions Virtualization", Weiping Xu, Yuanlong Jiang, Cathy Zhou, 2014-02-14, This document provides some YANG data models for Network Functions Virtualization (NFV). "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", Bodo Moeller, Adam Langley, 2014-05-31, This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. "MN IP reachability for the DMM", Chunshan Xiong, Liu Jianning, 2014-02-11, In distributed mobility management (DMM) environment, the mobile node (MN) has more than one IP addresses and can use different IP address to communicate with different hosts. When a new correspondent node (CN) initials an IP session with MN, the CN needs to find and select one of the MN's IP addresses to provide best performance (e.g. with low delay) for the IP session. This draft analyses the existing mechanisms for IP reachability in a distributed mobility management environment, and identifies the key procedures or enhancements to support the routing-optimized IP reachability in a distributed mobility management environment. "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", Joe Clarke, Gonzalo Salgueiro, Carlos Pignataro, 2014-06-07, 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. "Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP- TE) to Support Route Exclusion Using Path Key Subobject", Xian Zhang, Fatai Zhang, Oscar de Dios, Igor Bryskin, Dhruv Dhody, 2014-02-13, This document extends the Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit eXclusion Route Subobject (EXRS) within Explicit Route Object (ERO) to support specifying route exclusion requirement using Path Key Subobject (PKS). "Opportunistic Encryption for HTTP URIs", Mark Nottingham, Martin Thomson, 2014-05-19, This describes how "http" URIs can be accessed using Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. "Supporting Source/Explicitly Routed Tunnels via Stacked LSPs", Hannes Gredler, Yakov Rekhter, Luay Jalil, Sriganesh Kini, Xiaohu Xu, 2014-05-21, This document describes how source/explicitly routed tunnels could be realized using stacked Label Switched Paths (LSPs). This document also describes how use of IS-IS/OSPF as a label distribution protocol fits into the MPLS architecture. "Requirements for Service Function Chaining (SFC)", Mohamed Boucadair, Christian Jacquenet, Yuanlong Jiang, Ron Parker, Carlos Pignataro, Kengo, 2014-04-04, This document identifies the requirements for the Service Function Chaining (SFC). "Service Function Chaining: Framework & Architecture", Mohamed Boucadair, Christian Jacquenet, Ron Parker, Diego Lopez, Jim Guichard, Carlos Pignataro, 2014-02-13, IP networks rely more and more on the combination of advanced functions (besides the basic routing and forwarding functions) for the delivery of added value services. This document defines a reference architecture and a framework to enforce Service Function Chaining (SFC) with minimum requirements on the physical topology of the network. "Service Function Chaining: Design Considerations, Analysis & Recommendations", Mohamed Boucadair, Christian Jacquenet, Ron Parker, Linda Dunbar, 2014-02-12, This document aims at analyzing the various design options and providing a set of recommendations for the design of Service Function Chaining solution(s). Note: o The analysis does not claim to be exhaustive. The list includes a preliminary set of potential solutions; other proposals can be added to the analysis if required. o The analysis is still ongoing. The analysis text will be updated to integrate received comments and inputs. o Sketched recommendations are not frozen. These recommendations are provided as proposals to kick-off the discussion and to challenge them. o The analysis does not cover any application-specific solution (e.g., HTTP header) because of the potential issues inherent to (TLS) encrypted traffic. o The analysis will be updated to take into account the full set of SFC requirements. "IPPM Considerations for the IPv6 PDM Extension Header", Nalini Elkins, Keven Haining, Michael Ackermann, 2014-01-30, To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. These metrics are defined in the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). The base metrics are: packet sequence number and packet timestamp. Other metrics may be derived from these for use in diagnostics. This document specifies such metrics, their calculation, and usage. "Service Function Chaining (SFC) Architecture", Paul Quinn, Joel Halpern, 2014-05-05, 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. This document does not propose solutions, protocols, or extensions to existing protocols. "Test Vectors for the Stream Cipher ChaCha", Joachim Strombergson, 2013-12-31, This document contains test vectors for the stream cipher ChaCha using 8, 12 and 20 rounds as well as 128 and 256 bit keys. "Practical Issues with Datagram Transport Layer Security in Constrained Environments", Klaus Hartke, 2014-04-08, This document investigates practical issues around the implementation of Datagram Transport Layer Security (DTLS) 1.2 in constrained environments, and explores some ideas for an optimized version of DTLS 1.2 that is more friendly to constrained nodes and networks. "Network Service Header", Paul Quinn, Jim Guichard, Rex Fernando, Surendra, Michael Smith, Navindra Yadav, Puneet Agarwal, Rajeev Manur, Abhishek Chauhan, Uri Elzur, Brad McConnell, Chris Wright, 2014-02-14, This draft describes a Network Service Header (NSH) added to encapsulated packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. "Stateless Reconfiguration in Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Sheng Jiang, Bing Liu, 2014-02-14, This document defines a mechanism to propagate reconfigure messages towards stateless configured DHCPv6 clients. "A Link-Format Attribute for Locating Things", Thomas Fossati, 2014-02-12, This memo proposes a new CoAP link format attribute, "geo", that can be used to associate positioning metadata to a CoAP resource. An extension to the link format query syntax is also defined to allow the discovery of resources based on their geo location. "Service Function Chaining (SFC) Use Cases", Will, Hongyu Li, Oliver Huang, Mohamed Boucadair, Nicolai Leymann, Zhen Cao, Qiong, Chuong Pham, Changcheng Huang, Jiafeng Zhu, Peng He, 2014-05-28, The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). "Additional RTP Control Protocol (RTCP) Extended Report (XR) Metrics for WebRTC Statistics API", Varun Singh, Rachel Huang, Roni Even, 2014-02-14, This document describes a list of additional identifiers used in WebRTC's Javascript statistics API. These identifiers are a set of RTCP XR metrics related to the transport of multimedia flows. "Sleepy Devices: Do we need to Support them in CORE?", Akbar Rahman, 2014-02-11, This document summarizes the discussion in the CORE WG related to the question of whether support of sleepy devices is required for the CoAP protocol, CORE Link Format, CORE Resource Directory, etc. The only goal of this document is to trigger discussions in the CORE WG so that all relevant considerations for sleeping devices are taken into account. "Large Flow Use Cases for I2RS PBR and QoS", ramki, Anoop Ghanwani, Sriganesh Kini, Dave McDysan, Diego Lopez, 2014-04-03, This draft discusses two use cases to help identify the requirements for policy-based routing in I2RS. Both of the use cases involve identification of certain flows and then using I2RS to program routers with special handling for those flows. The first use case deals with improving bandwidth efficiency. Demands on networking bandwidth are growing exponentially due to applications such as large file transfers and those with rich media. Link Aggregation Group (LAG) and Equal Cost Multipath (ECMP) are extensively deployed in networks to scale the bandwidth. However, the static hash-based load balancing techniques used today make inefficient use of the bandwidth in the presence of long-lived large flows. We discuss how I2RS can be used for achieving better load balancing. The second use case is for recognizing and mitigating Layer 3-4 based DDoS attacks. Behavioral security threats such as Distributed Denial of Service (DDoS) attacks are an ongoing problem in today's networks. DDoS attacks can be Layer 3-4 based or Layer 7 based. We discuss how such attacks can be recognized and how I2RS can be used for mitigating their effects. "Flow high availability through PCP", Suresh Vinapamula, Senthil Sivakumar, 2014-06-13, This document describes a mechanism for a host to signal various network functions' High Availability (HA) module to checkpoint interested connections through PCP. "Optimistic Encryption using TLS Signaling in the DNS", Paul Hoffman, 2014-04-10, Many Internet servers offer content in two transports: unencrypted, and encrypted with TLS. A user who accesses some content with a URL that indicates unencrypted (such as "http:") might prefer to get the content encrypted but doesn't bother to, or can't, change the URL to indicate this. This proposal allows Internet clients, particularly web clients and mail user agents, to do a DNS lookup to see whether they might expect content for a particular host to also be available under TLS. Using the DNS for this is much faster than attempting a TLS session that might time out or take many round trips in order to discover that the content is not available. "Secure Automation and Continuous Monitoring (SACM) Requirements", Nancy Cam-Winget, 2014-06-08, This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring working group. The requirements and scope are based on the agreed upon use cases. "Using Partial Offers and Partial Answers in a Multimedia Session", Adam Roach, Suhas Nandakumar, 2014-02-14, Whenever two hosts have the ability to set up and control a session on a peer-to-peer basis, situations can arise in which both parties attempt to change session parameters "at the same time," such that the session control messages cross on the wire. When this happens, implementations need to invoke extraordinary procedures to return the shared state of the session to a common view between the endpoints. For real-time communications, these session control messages are typically exchanged using the session description protocol (SDP), using an Offer/Answer model. This document expands the offer/answer model to include the ability to exchange information relating to discrete media streams within the session. By reducing the amount of session data, the frequency of session state conflicts can be reduced; and, for certain types of operations, conflicts can be eliminated altogether. This document updates RFC 3264. "Stateless Client Identifier for OAuth 2", John Bradley, 2014-04-07, This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. "Extensions to Path Computation Element Communication Protocol (PCEP) for handling the Link Bandwidth Utilization", Wenson Wu, Dhruv Dhody, Stefano Previdi, 2014-06-24, 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 Link bandwidth utilization (the total bandwidth of a link in current use for the forwarding) is an important factor to consider during path computation. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] define mechanisms that distribute this information via OSPF and ISIS respectively. This document describes extensions to PCEP to use them as new constraints during path computation. "An Architecture of Service Function Chaining", Yuanlong Jiang, Li Hongyu, 2014-02-14, As network virtualization is opening the gate to much more innovative services for service providers, Service Function Chaining (SFC) provides a flexible way of service provisioning and facilitates their deployments. This document provides a general abstract architecture for service chaining. It is a flexible and scalable architecture which can fulfill requirements of SFC. Some solutions based on this architecture are also discussed and compared. This architecture can be used as a guideline and also a criterion for the design of SFC. "Secure initial-key reconfiguration for resource constrained devices", Namhi Kang, Seung-Hun Oh, Shimkwon Yoon, 2014-02-10, This document presents a secure method to configure a key for a resource constrained node when it initially joins to network that is currently in operation. The method is suited for a scenario, where resource constrained nodes are interconnected with each other and thus form a network called Internet of Things. It is assumed that communications for all nodes are based on TCP/IP protocols and the nodes use the constrained application protocol (CoAP). The presented method does not cover all operations of secure bootstrapping for IoT networks, but it is intended to securely support self-reconfiguration of the pre-installed temporary key of joined node. "Authenticated Encryption with Replay prOtection (AERO)", David McGrew, John Foley, 2014-02-14, This document describes Authenticated Encryption with Replay prOtection (AERO), a cryptographic technique that provides all of the essential security services needed for communication security. AERO offers several advantages over other methods: it has more compact messages, provides stronger misuse resistance, avoids the need to manage implicit state, and is simpler to use. This document defines a particular AERO algorithm as well as a registry for such algorithms. "The 'XML2RFC' version 2 Vocabulary", Julian Reschke, 2014-06-22, This document defines the 'XML2RFC' version 2 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. 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 . "Architecture for Chaining Legacy Layer 4-7 Service Functions", Linda Dunbar, Ron Parker, So Ning, Donald Eastlake, 2014-04-30, This draft describes the architecture for chaining existing L4-L7 service functions that don't have Layer 2-3 switching/routing capability and are not aware of newly defined service encapsulation layer. The intent is to identify optimal architecture for flexibly chaining existing Layer 4-7 functions to meet various service needs. "Configuration Discovery and Negotiation Protocol for Network Devices", Sheng Jiang, Brian Carpenter, Bing Liu, 2014-06-25, This document defines a new protocol that enables intelligent devices to dynamically discover and negotiate their configuration with counterpart devices. This document only defines a general protocol as a negotiation platform while the negotiation objectives for specific scenarios are to be described in separate documents. "IETF Working Groups' Secretaries", Martin Vigoureux, Daniel King, Carlos Pignataro, 2014-06-12, The Working Group Secretary's role was succinctly defined in RFC 2418. However, this role has greatly evolved and increased both in value and scope, since the writing of RFC 2418. This document updates RFC 2418 by providing a new definition of the Working Group Secretary's role. This document also provides a compilation of good practices and general guidelines regarding the fulfilment of the role. This document is intended for established Working Group Secretaries, individuals motivated by taking up that role, or anyone else simply interested in understanding better the Working Group Secretary's role. This document may also be useful for Working Group Chairs to better appreciate and help develop the value of Working Group Secretaries. "LLN Fragment Forwarding and Recovery", Pascal Thubert, Jonathan Hui, 2014-02-14, In order to be routed, a fragmented packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. "DTLS-based Multicast Security in Constrained Environments", Sye Keoh, Sandeep Kumar, Oscar Garcia-Morchon, Esko Dijk, Akbar Rahman, 2014-05-09, The CoAP standard is fast emerging as a key protocol in the area of resource-constrained devices. Such IP-based systems are foreseen to be used for building and lighting control systems where devices interconnect with each other, forming, for example, low-power and lossy networks (LLNs). Both multicast and its security are key needs in these networks. This draft presents a method for securing IPv6 multicast communication based on the DTLS which is already supported for unicast communication for CoAP devices. This draft deals with the adaptation of the DTLS record layer to protect multicast group communication, assuming that all group members already have the group security association parameters in their possession. The adapted DTLS record layer provides message confidentiality, integrity and replay protection to group messages using the group keying material before sending the message via IPv6 multicast to the group. "Use case for a scalable and topology aware MPLS data plane monitoring system", Ruediger Geib, Clarence Filsfils, 2014-02-05, 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. "Notifying RTSP Clients and Proxy Servers About Streams: The RTSP "REGISTER" Command", Ross Finlayson, 2014-04-17, We define a new RTSP command - named "REGISTER" - that allows a server (or a third party) to notify a RTSP client or a RTSP proxy server about a RTSP stream (given by a "rtsp://" URL). This also provides a mechanism whereby a client (or proxy server) on the public Internet can access a RTSP server that is behind a firewall or NAT. "OSPFv3 Extensions for Segment Routing", Peter Psenak, Stefano Previdi, Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, 2014-02-14, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary OSPFv3 extensions that need to be introduced for Segment Routing. "Layer-2 security aspects for the IEEE 802.15.4e MAC", Giuseppe Piro, Gennaro Boggia, Luigi Grieco, 2014-06-13, The aim of this Internet Draft is to define standard compliant procedures for configuring layer-2 security services in IEEE 802.15.4e-based Low-power and Lossy Networks. In particular, it provides a review of security aspects presented in both IEEE 802.15.4 and IEEE 802.15.4e specifications, the classification of secure network configurations and layer-2 keys, the description of a set of consecutive steps required to establish a layer-2 secure link, and a lightweight Key Management Protocol designed for negotiating a layer-2 one-hop link key. As the final goal, the document would describe how security MAC attributes can by initialized and updated in order to offer layer-2 security services in real networks. "OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels", Anton Smirnov, Alvaro Retana, Michael Barnes, 2014-04-14, 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. "Application-oriented Stateful PCE Architecture and Use-cases for Transport Networks", Young Lee, Xian Zhang, zhenghaomian@huawei.com, Guoying Zhang, 2014-02-14, This draft presents an application-oriented stateful PCE architecture for transport networks. Under this architecture, several use cases are described. "Browser processing of server certificates", Ben Wilson, Santosh Chokhani, Robin Alden, 2014-06-09, This is one of a set of documents to define the operation of the Web PKI. It describes common variations in browser behavior related to processing server certificates. "A Unified LISP Mapping Database for L2 and L3 Network Virtualization Overlays", Yves Hertoghs, Fabio Maino, Victor Moreno, Michael Smith, Dino Farinacci, Luigi Iannone, 2014-02-12, The purpose of this draft is to document how the Locator/ID Separation Protocol (LISP) Control Plane can be used to offer a unified (offering L2 AND L3) Overlay solution that matches the framework and requirements of Network Virtualization over L3 (NVO3). This information is provided as input to the NVO3 analysis of the suitability of existing IETF protocols to the NVO3 requirements. "Proactive fault detection in EVPN", Vengada Govindan, Samer Salam, Ali Sajassi, 2014-02-13, This document proposes a proactive, in-band network OAM mechanism to detect connectivity faults that affect unicast and multi-destination paths in an EVPN network. The multi-destination paths are used by Broadcast, unknown Unicast and Multicast (BUM) traffic. The mechanisms proposed in the draft use the principles of the widely adopted Bidirectional Forwarding Detection (BFD) protocol. "Ideas for a Next Generation of the Reliable Server Pooling Framework", Thomas Dreibholz, 2014-01-04, This document collects some idea for a next generation of the Reliable Server Pooling framework. "NETCONF Efficiency Extensions", Andy Bierman, 2014-04-21, This document describes protocol extensions to improve the efficiency of the Network Configuration Protocol (NETCONF). Protocol capabilities and operations are defined to reduce network usage and transaction complexity. "Problem Statement for IP measurement in mobile networks", Deng Lingli, Zhen Cao, 2014-02-13, This document analyzes the potential problems of applying existing IP-based performance measurement methods to wireless accessing environments. It suggests that a more flexible passive measuring framework and performance metrics, such as congestion ratio are needed. "What's the Impact of Virtualization to ALTO?", Qiao Fu, Zehn Cao, Haibin Song, 2014-02-12, This draft 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 Network Functions Virtualisation (NFV), as 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 usecase presented in this draft discusses the impact of virtualization on the ALTO protocol. "Use Cases for an Interface to MPLS TE", Tieying Huang, Zhenbin Li, Susan Hares, 2014-02-14, Network services based on Virtual Networks (VN) or Virtual Circuits (VC) may be run over MPLS-TE links, and support network configurations such as hub-spoke, service routing, or on-demand networks. An MPLS Traffic Engineering(TE) network is typically configured and the results of its operation analyzed through network management interfaces (CLI, SNMP or NETCONF). These interactions to control each of the MPLS TE links, and diagnose operations issues concerning link configuration, MPLS TE protection, and traffic switching-over. The network management functions also monitor MPLS TE links and provide fault detection. The Interface to the Routing System (I2RS) (draft-ietf-i2rs- architecture) programmatic interface to the routing system provides an alternative way to control the configuration and diagnose the operation of MPLS links. I2RS may be used for the configuration, manipulation, polling or analyzing MPLS TE. This document describes a set of use cases for which I2RS can be used for MPLS TE. It is intended to provide a base for a solution draft describing I2RS information models and protocol functions that will support virtual networks that utilize MPLS TE. "Network Assigned Upstream-Label", Vishnu Beeram, Igor Bryskin, 2014-02-14, This document discusses GMPLS RSVP-TE protocol mechanisms that enable 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. "DHCP Options for Homenet Naming Architecture", Daniel Migault, Wouter Cloetens, Chris Griffiths, Ralf Weber, 2014-02-13, The home network naming architecture requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. "Segment Routing with MPLS data plane", Clarence Filsfils, Stefano Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Igor Milojevic, Rob Shakir, Saku Ytti, Wim Henderickx, Jeff Tantsura, Edward Crabbe, 2014-06-06, 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. "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, 2014-04-18, 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. "Trustable Cloud Systems - Strategies and Recommendations", Cullen Jennings, Suhas Nandakumar, 2014-01-15, The Internet technical community is looking at ways to address pervasive attacks as described in several other internet drafts. [I-D.barnes-pervasive-problem] describes threat model to characterize various pervasive attacks on the Internet communications. There are many systems that need to be secured against such attacks but this paper considers one possible way to secure cloud based collaborations systems. At a high level, this paper sugests that users or enterprises could run a key server that manages the keys to access their content. The cloud service provider would not have access to decrypt the data stored in the cloud but various users of the cloud service could get the keys to encrypt and decrypt the contents of collaboration sessions facilitated by the cloud service. This does not protect the meta data of who is talking to who but can help protect the content of the conversations. "Transmission Control Protocol Specification", Wesley Eddy, 2014-03-27, 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. "Use Cases of I2RS in Mobile Backhaul Network", Li Zhang, Zhenbin Li, Dapeng Liu, Susan Hares, 2014-02-14, In a mobile backhaul network, traditional configuration and diagnoses mechanisms based on device-level management tools and manual processing are ill-suited to meet the requirements of today's scalable, flexible, and complex network. Thanks to the new innovation of Interface to the Routing System's (I2RS) programmatic interfaces, as defined in [I-D.ietf-i2rs-architecture], an alternative way is available to control the configuration and diagnose the operational results. This document discusses the use case for I2RS in mobile backhaul network. "ALTO Traffic Engineering Cost Metrics", Wenson Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy, 2014-02-13, 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. "L2TP-VP: Layer Two Tunneling Protocol - Virtualization Profile", Duoliang Fan, Liang Xia, Zehn Cao, Namgon Kim, 2014-04-09, This document describes Layer Two Tunneling Protocol (L2TP)'s virtualization profile (L2TP-VP), which reuses session header of L2TP data message to securely support overlay networks for multiple tenants, and simplifies tunnel setup by disabling all kinds of L2TP control messages. "The "safe" HTTP Preference", Mark Nottingham, 2014-05-30, This specification defines a "safe" preference for HTTP, expressing a user preference to avoid "objectionable" content. "Security Framework and Key Management Protocol Requirements for 6TiSCH", Stephen Chasko, Subir Das, Rafael Lopez, Yoshihiro Ohba, Pascal Thubert, Alper Yegin, 2014-03-22, 6TiSCH is enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard that allows the IEEE 802.15.4e TSCH wireless networks and nodes to connect to the backbone network via layer 3 meshes over IPv6. In this operation of network architecture, understanding the security framework and requirements for key management protocols are critical. This document discusses such security framework and key management protocol requirements by highlighting different phases of key management in which a new node can securely join the network under the purview of overall 6TiSCH architecture. "Pronouncing and Using Chinese Personal Names", Hui Deng, Zehn Cao, Paul Hoffman, 2014-04-24, 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. "Service Function Chain Control Plane Overview", Qin Wu, Wang Danhua, Mohamed Boucadair, XianGuo Zhang, Yang Shi, 2014-02-13, As described in [I.D-boucadair-sfc-framework], the dynamic enforcement of a Service-derived, adequate forwarding policy for packets entering a network that supports such advanced Service Functions has become a key challenge for operators and service providers. This document is based on [I.D-boucadair-sfc-framework] and focusing on discussing how the Service Functions are discovered and provisioned and how Service Function Chaining path is setup. "I2RS Use Cases for Control of Forwarding Path by Central Control Network Element (CCNE)", Xiaofeng Ji, Shunwan Zhuang, Tieying Huang, Susan Hares, 2014-02-14, As network expand bridging access, Data Center and WAN, more networks have a central control point for the network elements in one administrative domain. This document defines that network device as central control network element (CCNE). The CCNE can be RR Router, PCE Server, or a federation of RR Router and PCE Server, or other devices. This document describes use case where the CCNE can utilize both these the traditional functions and the programmatic Interface to Routing System (I2RS) to communicate with devices in the network. The I2RS use cases described in this document encompass: Control IP Network by RR Router, Control MPLS TE Network by PCE Server. The goal of this document is to inform the community's understanding of how CCNE extensions fit within the overall I2RS architecture. It is intended to provide a basis for the solutions draft describing the set of interfaces for the CCNE device. "Problem Statement for Openv6 Scheme", Qiong, Will, Cathy Zhou, 2014-02-14, This document assesses the variety and complexity of IPv6 deployments, and proposes a new space of study to simplify the enablement of new IPv6 applications on an existing network. The document evaluates the identified technical gaps as well. "Openv6 Architecture for IPv6 Deployment", Will, Cathy Zhou, Qiong, 2014-02-14, IPv6 transition leads to costly end-to-end network upgrades and poses new challenges in terms of device management with a variety of transitional protocols. This document provides a cost-effective and flexible unified IPv6 deployment by describing an architecture of a standard and programmatic manner for IPv6 deployment. "Multi-chassis PON Protection in MPLS", Yuanlong Jiang, Yong Luo, Edwin Mallette, Chengbin Shen, Yimin Shen, 2014-04-01, 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. "Advertising per-node administrative tags in OSPF", Shraddha Hegde, Harish Raghuveer, Hannes Gredler, Rob Shakir, Anton Smirnov, 2014-02-14, 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 the protocol extensions to disseminate per- node admin-tags to the OSPFv2 and OSPFv3 protocol. "Multiple Language Content Type", Nik Tomkinson, Nathaniel Borenstein, 2014-04-16, 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. "Routing Optimization with SDN", yangun@dcn.ssu.ac.kr, Young-Han Kim, 2014-04-21, 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, 2014-02-14, This document describes mechanisms for IS-IS to be self-configuring. Such mechanisms could reduce the management burden to configure a network. One obvious environment that could benefit from these mechanisms is IPv6 home network where plug-and-play would be expected. Besides home network, some simple enterprise/ISP networks might also benefit from the self-configuring mechanisms. "Advertising Per-node Admin Tags in IS-IS", psarkar@juniper.net, Hannes Gredler, Shraddha Hegde, Harish Raghuveer, Stephane Litkowski, Bruno Decraene, 2014-02-14, This document describes an extension to IS-IS protocol [ISO10589], [RFC1195] to add an optional operational capability, that allows tagging and grouping ofthe 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 admin-tags in IS-IS protocols. "Transmission of IPv6 Packets over IEEE 802.11p Networks", Alex Petrescu, Pierre Pfister, Nabil Benamar, Tim Leinmueller, 2014-06-16, In order to transmit IPv6 packets on IEEE 802.11p networks there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, the header format preceding the IPv6 base header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11p networks; it portrays the layering of IPv6 on 802.11p similarly to other known 802.11 and Ethernet layers, by using an existing Ethernet Adaptation Layer. In addition, the document attempts to list what is different in 802.11p compared to more 'traditional' 802.11a/b/g/n layers, layers over which IPv6 protocols run ok. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. An example of an IPv6 packet captured while transmitted over an IEEE 802.11p link is given. "DTLS Relay for Constrained Environments", Sandeep Kumar, Sye Keoh, Oscar Garcia-Morchon, 2014-04-22, The 6LoWPAN and CoAP standards defined for resource-constrained devices are fast emerging as the de-facto protocols for enabling the Internet-of-Things (IoTs). Security is an important concern in IoTs and the DTLS protocol has been chosen as the preferred method for securing CoAP messages. DTLS is a point-to-point protocol relying on the IP routing to deliver messages between the client and the server. However in some low-power lossy networks (LLNs) with multi-hop, a new "joining" device may not be initially IP routable until it is authenticated to the network. This prevents DTLS from being directly useful as an authentication and confidentiality protocol during this stage, requiring other security protocols to be implemented on the device. These devices being resource-constrained often cannot accommodate more than one security protocol in their code memory. To overcome this problem and reuse DTLS, we present a DTLS Relay solution for the non-IP routable "joining" device to establish a secure DTLS connection with a DTLS server. Further we present a stateful and stateless mode of operation for the DTLS Relay. "Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti Kompella, Senad Palislamovic, 2014-06-17, This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. "IMAP UNAUTHENTICATE for Connection Reuse", Chris Newman, 2014-04-14, This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. "The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL)", Thomas Dreibholz, Michael Tuexen, Melinda Shore, Ning Zong, 2014-04-22, This draft describes the application of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL). "Cloud Based Mobile Core Network Problem Statement", Dapeng Liu, Kok-kiong Yap, Charles Perkins, Tao Sun, Hui Deng, 2014-02-14, This document introduces a cloud based mobile core network architecture. The motivation and the key problems that need to be further studied by the community are analyzed. The purpose of this document is to call the community's attention and interest to study the key technologies and protocols to realize this cloud based mobile core network. "Structure of the GSS Negotiation Loop", Benjamin Kaduk, 2014-01-14, This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. "PID Property Extension for ALTO Protocol", Bill Roome, Yang Yang, 2014-02-13, This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [I-D.ietf-alto-protocol] by defining PID-based properties in much the same way that the original ALTO Protocol defines endpoint-based properties. "Auditing of Congestion Exposure (ConEx) signals", David Wagner, Mirja Kuehlewind, 2014-02-14, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. This document defines how the signals are handled by an audit and lists requirements for an audit implementation. This document does not mandate a particular design but identifies state and functions that any auditor element must provide to fullfil the requirements stated in [draft-ietf-conex-abstract-mech]. "Traffic Engineering Database dissemination for Hierarchical PCE scenarios", Victor Lopez, Oscar de Dios, Daniel King, Stefano Previdi, 2014-02-12, The PCE architecture is well-defined and may be used to compute the optimal path for LSPS across domains in MPLS-TE and GMPLS networks. The Hierarchical Path Computation Element (H-PCE) [RFC6805] was developed to provide an optimal path when the sequence of domains is not known in advance. The procedure and mechanism for populating the Traffic Engineering Database (TED) with domain topology and link information used in H-PCE-based path computations is open to interpretation. This informational document describes how topology dissemination mechanisms may be used to provide TE information between Parent and Child PCEs (within the H-PCE context). In particular, it describes how BGP-LS might be used to provide inter- domain connectivity. This document is not intended to define new extensions, it demonstrates how existing procedures and mechanisms may be used. "Larger Packets for RADIUS over TCP", Sam Hartman, 2014-02-13, 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 to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. "CDNI Rate Pacing", Matt Caulfield, 2014-02-13, Rate pacing is a class of network traffic shaping which limits the transmission rate of data over a network. This document defines CDNI extensions for downstream CDNs to support rate pacing on behalf of upstream CDNs. "OSPF Two-part Metric", Lili Wang, Dave DuBois, Vibhor Julka, Tom McMillan, 2014-06-10, 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. "Shared Resource Link Group (SRcLG)", Vishnu Beeram, Igor Bryskin, 2014-02-12, This document introduces the concept of SRcLG ("Shared Resource Link Group") and discusses its usage in the context of mutually exclusive Virtual TE Links. "Diameter Agent Overload", Steve Donovan, 2014-02-14, This specification documents an extension to the Diameter Overload Control (DOC) base solution. The extension addresses the handling of agent overload. Requirements "Hybrid Unicast/Multicast DNS-Based Service Discovery", Stuart Cheshire, 2014-01-22, Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) of services that are outside the local link. Using a very large local link with thousands of hosts improves service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient, but requires configuration of DNS Update keys on the devices offering the services, which can be onerous for simple devices like printers and network cameras. Hence a compromise is needed, that provides easy service discovery without requiring either large amounts of multicast traffic or onerous configuration. "RSVP-TE Extensions for RRO Editing", Matt Hartley, Zafar Ali, Oscar de Dios, Cyril Margaria, Xian Zhang, 2014-02-14, This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to allow the communication of changes made by a node to the information provided by other nodes in a ROUTE_RECORD Object (RRO) in Path and Resv messages, or to indicate that it has itself provided incomplete information. "Support for multiple provisioning domains in DHCPv6", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, 2014-02-14, 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. "Extensions to the PMIPv6 Access Network Identifier Option", Rajesh Pazhyannur, Sebastian Speicher, Sri Gundavelli, Jouni Korhonen, John Kaippallimalil, 2014-03-03, Access Network Identifier (ANI) Mobility option was introduced in [RFC6757] enabling a MAG to convey information like network identifier, geo-location, operator-identifier. This specification extends Access Network Identifier mobility option with sub-options to carry Civic Location and MAG Group Identifer This specificaton also defines a ANI update timer sub-option that informs the the LMA when (and how often) the ANI will be updated. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Additional Signal Types in G.709 OTN", Zafar Ali, Antonello Bonfanti, Fatai Zhang, 2014-03-06, [I-D.draft-ietf-ccamp-gmpls-signaling-g709v3] provides the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU4, ODU2e and ODUflex. However, it does not cover additional signal types mentioned in [G.Sup43] (ODU1e, ODU3e1, ODU3e2). This draft provides GMPLS signaling extension for these additional signal types. "Residence Time Measurment in MPLS network", Greg Mirsky, John Drake, Stewart Bryant, Sasha Vainshtein, 2014-04-21, This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. "Yang Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Alex Clemm, 2014-02-14, This document defines a YANG data model that can be used to configure and manage OSPF. "PCE Path Profiles", Santiago Alvarez, Siva Sivabalan, Zafar Ali, Luis Tomotaki, Victor Lopez, 2014-03-04, This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to signal path profile identifiers. A profile represents a list of path parameters or policies that a PCEP peer may invoke on a remote peer using an opaque identifier. When a path computation client (PCC) initiates a path computation request, the PCC can signal profile identifiers to invoke path parameters or policies defined on the PCE which would influence the path computation. Similarly, when a PCE initiates or updates a path, the PCE can signal profile identifiers to invoke path parameters or policies defined on the PCC which would influence the path setup. "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", Jouni Korhonen, Suresh Krishnan, Sri Gundavelli, 2014-02-14, 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. "Service Provider Edge Router Interaction", Timothy Winters, 2014-02-14, This document describes the interaction between a Service Provider Gateway fixed at the home edge, and the Home Networking interior routers. It assesses the interactions between existing routers implementing [RFC7084] and the Home Networking routers. The document will also define the interactions between other Service Provider Edge Router (eg. HIPnet) and Home Networking router. "Use Cases and Requirements for MPLS-TP multi-failure protection", Zhenlong Cui, Rolf Winter, 2014-02-14, MPLS Transport Profile (MPLS-TP) linear protection is defined in [RFC6378]. That however is limited to 1+1 and 1:1 protection and is not able to care that the multiple failures are occurred on both working and protection paths. This document describes why we need to consider the case for multiple failures, and lists some requirements for multi-failure protection (MFP) functionality. "Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)", Kent Watsen, Stephen Hanna, Joe Clarke, Mikael Abrahamsson, 2014-02-13, This draft presents a technique for how to establish a secure NETCONF connection between a newly deployed networking device, configured with just its factory default settings, and the new owner's Network Management System (NMS). "Deployable Enhanced Email Privacy (DEEP)", Keith Moore, Chris Newman, 2014-02-14, This specification defines a set of requirements and facilities designed to improve email privacy. The focus of this proposal is to provide mechanisms intended to increase use of already deployed Transport Layer Security (TLS) technology and enable deployment and use of stronger cipher suites for email protocols. "A DTLS 1.2 Profile for the Internet of Things", Klaus Hartke, Hannes Tschofenig, 2014-02-14, This document defines a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. "PCP Extension for Signaling Feedback Information from the End-User Application to the Application Sever and to the Network", Hassnaa Moustafa, Danny Moses, Mohamed Boucadair, 2014-05-06, Nowadays users consumption style for video and multimedia applications is strongly changing. Users are consuming content through multi-screen and are heavily counting on wireless and mobile devices for video streaming and interactive video and multimedia applications. This necessitates more intelligence in the service and the network infrastructure to better suit a differentiated users consumption style, which can be achieved through having: (i) a knowledge in the network and service platform about the available device and network conditions for the end-user and (ii) a knowledge in the network about the content requirements in terms of devices capabilities and network resources for content stored either in the network or in the application server. To obtain such knowledge with no need for changing the current infrastructure and in a generalized way to all applications, feedback/notification mechanisms between the end-user application, the network and the service platform is needed to provide information helping the content delivery and adaptation decisions. This document is investigating such application-agnostic track. This document extends the Port Control Protocol (PCP) RFC 6887 [RFC6887] to allow: (i) the users application to notify the network and application server about its available resources in terms of devices capabilities and network conditions as well as information about the user (e.g., location, mobility status) and (ii) the application server to notify the network about the requirements of the content it stores in terms of devices and network resources. A new PCP option, denoted the FEEDBACK, is specified to allow such feedback notification signaling. This option is used with both PEER and MAP Opcodes. "Network Virtualization Edge (NVE)", Lucy Yong, Zu Qiang, 2014-06-18, This document specifies Network Virtualization Edge (NVE) data plane interoperability functionality for Network Virtualization Overlays (NVO3). These specifications are necessary for the interoperability between an NVE and its attached tenant systems and between the NVEs. "Internet Protocol-based In-Vehicle Emergency Calls", Randy, Brian Rosen, Hannes Tschofenig, 2014-02-14, 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). Profiling and simplifications are possible due to the nature of the functionality that is provided in vehicles with the usage of Global Satellite Navigation System (GNSS). "Next-Generation Pan-European eCall", Randy, Hannes Tschofenig, 2014-02-14, This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required by 2015 in European Union member states, and eCall is 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. "Inter-domain SLA Exchange Implementation Report", Shitanshu Shah, Keyur Patel, 2014-04-30, 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 and an inter-operability results between implementations from 2 different Cisco OS. "Validation of Locations Around a Planned Change", Brian Rosen, 2014-02-14, This document defines an extension to LoST (RFC5222) that allows a planned change to the data in the LoST server to occur. Records that previously were valid will become invalid at a date in the future, and new locations will become valid after the date. The extension adds two elements to the request: a URI to be used to inform the LIS that previously valid locations will be invalid after the planned change date, and add a date which requests the server to perform validation as of the date specified. It also adds a TTL element to the response, which informs all queriers the current expected lifetime of the validation. "SPRING Use Cases for Software-defined Networking", Sungsu Kim, Jaewoo Park, EunKyoung Paik, Luis Contreras, 2014-02-14, In the Software-Defined Networking (SDN) architecture, an SDN controller establishes flow paths. An SDN controller provides global optimization of paths by controlling all managed switches. However, long flow setup time and failure recovery problems arise due to control overhead of an SDN controller. Segment routing provides source routing function by designating an explicit path. SDN and segment routing can be combined to provide both global optimization and performance enhancement. In this document, we illustrate SDN segment routing use cases of flow setup, failure recovery, Content Distribution Network(CDN), and dual homing. "A Statement", Martin Thomson, 2014-01-27, This document contains a response to revelations of systematic surveillance by state actors. "New Handshake Flows for TLS 1.3", Eric Rescorla, 2014-02-19, This document sketches some potential new handshake flows for TLS 1.3. "Clarification of the Flowspec Redirect Extended Community", Jeffrey Haas, 2014-02-05, This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575. "Snapshot of OLSRv2-Routed MANET Management", Thomas Clausen, Ulrich Herberg, 2014-02-11, 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 routing protocol OLSRv2 and its constituent protocol NHDP. Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single 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 can be sent to the Network Management Station (NMS) via standardized management protocols. "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. "Extension Frames in HTTP/2", Mike Bishop, 2014-05-22, This document describes a proposed modification to the HTTP/2 specification to better support the creation of extensions without the need to version the core protocol or invoke additional protocol identifiers. "Special-Use Domain Names of Peer-to-Peer Systems", Christian Grothoff, Matthias Wachs, hellekin, Jacob Appelbaum, 2014-03-03, This is an IESG Approval document requesting the reservation of six Top-Level Domains for special use, in conformance with the registration procedure defined in RFC 6761, section 4. Peer-to-Peer systems use specific decentralized mechanisms to allocate, register, manage, and resolve names. Those mechanisms operate entirely outside of DNS, independently from the DNS root and delegation tree. In order to avoid interoperability issues with DNS as well as to address security and privacy concerns, this document describes six pseudo Top-Level Domain names (pTLDs), reserved for special use. The following six domains relate to security-focused peer-to-peer systems. They are: ".gnu", ".zkey", ".onion", ".exit", ".i2p", and ".bit". "SMTP IPv6 to IPv4 Fallback: An Applicability Statement", Franck Martin, Alec Peterson, 2014-05-15, This Applicability Statement describes how Mail Transfer Agents (MTAs) can be encouraged to fall back to IPv4 when a message is refused over IPv6. "Detection and Quantification of Packet Reordering with TCP", Alexander Zimmermann, Lennart Schulte, Carsten Wolff, Arnd Hannemann, 2014-05-20, This document specifies an algorithm for the detection and quantification of packet reordering for TCP. In the absence of explicit congestion notification from the network, TCP uses only packet loss as an indication of congestion. One of the signals TCP uses to determine loss is the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when paths reorder packets. This results in degraded performance. The algorithm for the detection and quantification of reordering in this document uses information gathered from the TCP Timestamps Option, the TCP SACK Option and its DSACK extension. When a reordering event is detected, the algorithm calculates a reordering extent by determining the number of segments the reordered segment was late with respect to its position in the sequence number space. Additionally, the algorithm computes a second reordering extent that is relative to the amount of outstanding data and thus provides a better estimation of the reordering delay when other sender state changes. "Making TCP Adaptively Robust to Non-Congestion Events", Alexander Zimmermann, Lennart Schulte, Carsten Wolff, Arnd Hannemann, 2014-05-20, This document specifies an adaptive Non-Congestion Robustness (aNCR) mechanism for TCP. In the absence of explicit congestion notification from the network, TCP uses only packet loss as an indication of congestion. One of the signals TCP uses to determine loss is the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when paths reorder packets. This results in degraded performance. TCP-aNCR is designed to mitigate this performance degradation by adaptively increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP and TCP-NCR (on which this specification is build on) and discusses the costs and benefits of these modifications. "Extensions to WHois service to allow query on email identities", pradeep xplorer, 2014-06-02, 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. "Traffic peeking", S Moonesamy, 2014-05-25, In June 2013, a news article revealed that the National Security Agency obtained direct access to the systems of several service providers from the United States through an undisclosed surveillance programme called PRISM. This document discusses about the practice of traffic peeking. "Possible Attack on Cryptographically Generated Addresses (CGA)", Hosnieh, Christoph Meinel, 2014-02-08, This document describes the new vulnerability with the use of Cryptographically Generated Addresses. "Single SignON solution to WWW seen as one Giant computer", pradeep xplorer, 2014-06-01, The document describes a SingleSignON solution to WWW seen as one Giant computer. As WWW use increases, on average an user has many service login accounts they have to manage. It would be better for most users at the expense of some security risk to have one password for all the services and a WWW shell and a control panel. Also the WWW as an intelligent being could show information to an user interpreting their needs from all their accounts. "Information as a bird with wings that flies and hits the user device screen as Icons", pradeep xplorer, 2014-04-03, 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. "DNS privacy considerations", Stephane Bortzmeyer, 2014-04-27, This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be mostly an analysis of the present situation, in the spirit of section 8 of [RFC6973] and it does not prescribe solutions. Discussions of the document should take place on the dns-privacy mailing list [dns-privacy]. "Confidential DNS", Wouter Wijngaards, Glen Wiley, 2014-03-10, This document offers opportunistic encryption to provide privacy for DNS queries and responses. "Universally Traceable Identifier (UTID)", huangng@gmail.com, 2014-05-28, 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, 2014-05-28, 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, 2014-05-28, 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. "Frame Duplication Avoidance For TRILL Active-Active Access", Hao Weiguo, Li Yizhou, Zhibo Hu, 2014-02-13, The problems in active-active connection to TRILL campus was introduced in [TRILL-Active-PS]. Frame duplication was a well recognized issue in that scenario. This draft proposes a Designated Forwarder (DF) mechanism to solve the issue of frame duplications. The basic idea is to elect one RBridge per VLAN from an edge group to be responsible for egressing the multicast frames. An edge group is a group of edge RBridges that a CE is multi-homed to in active- active mode. TRILL protocol extension for DF election is described in this draft. "ICN based Architecture for IoT", Yanyong Zhang, Dipankar Raychadhuri, Ravi Ravindran, Guoqiang Wang, 2014-06-03, Internet of Things (IoT) promises to connect billions of objects to Internet. After deploying many stand-alone IoT systems in different domains, the current trend is to develop a unified IoT platform so that objects can be made accessible to applications across organizations and domains. Towards this goal, quite a few proposals have been made to build a unified IoT platform as an overlay on today's Internet. Such an overlay solution, however, is inadequate to address the important challenges posed by a unified IoT system, especially in terms of mobility, scalability, and communication reliability, due to the inherent inefficiencies of the current Internet. To address this problem, we propose to build a unified IoT platform based on the Information Centric Network (ICN) architecture, which we call ICN-IoT. ICN-IoT leverages the salient features of ICN, and thus provides seamless mobility support, scalability, and efficient content and service delivery. In this proposal, we first present a few popular IoT scenarios in smart homes, smart grid, smart transportation, and smart healthcare. Then we identify a list of important requirements with the unified IoT architecture that promises to support tens of billions of objects. After discussing the weaknesses of the current overlay- based IoT solution, we propose an ICN-based solution, ICN-IoT, which can sufficiently satisfy these requirements. We present an example ICN-IoT architecture and discuss how it supports efficient data discovery, data processing and data distribution. Finally, we show that ICN-IoT efficiently supports context- based scenarios, which are very common for many IoT applications. "Use Cases and Requirements", Marie-Jose Montpetit, Igor Zhovnirovsky, 2014-02-03, This document describes some of the services and application use cases that may require specific transport services over an Internet subnetwork. It also presents, when available, some derived requirements and conditions of utilization that will allow to choose the most appropriate transport service. The use cases assume that choice of transport service is fully based on the requirements. In all cases however, the fallback is considered to be TCP or UDP. "6TiSCH On-the-Fly Scheduling", Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura, 2014-02-14, This document describes the environment, problem statement, and goals of the On-The-Fly (OTF) scheduling approach for the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. 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. The soft cell and Bundle reservation with OTF is distributed: through the 6top interface, neighbor nodes negotiate the cell(s) to be (re)allocated/deleted, without intervention 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 soft cells to be reserved/deleted; it is up to 6top to select the specific soft cells within the TSCH schedule. "The ChaCha Stream Cipher for Transport Layer Security", Adam Langley, Wan-Teh Chang, Nikos Mavrogiannopoulos, Joachim Strombergson, Simon Josefsson, 2014-03-03, This document describes the use of the ChaCha stream cipher with HMAC-SHA1 and Poly1305 in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. "Protocol independent multicast- Next Generation (PIM-NG): Protocol Specifications", saeed sami, 2014-06-09, 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. "Differentiation authentication for ABFAB", juanwei2012@gmail.com, Jianyong Chen, Jun Zhang, 2014-06-09, This document describes how to implement the differentiation authentication with Level of Assurance (LOA). In order to achieve the goal, we define a new authentication context class schema for SAML V2.0 which is used to specify the LOA requirement of Relying Provider (RP), a function which is used by Identity Provider (IdP) to transform the required LOA to specific authentication method(s), and a profile which describes the application of this new authentication context. "CoAP Option Extension: NodeId", Kepeng Li, Gengyu Wei, 2014-06-24, CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the NodeId Option. This Option can be used to identify the node, either the client or the server. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Centralized Replication for BUM traffic in active-active edge connection", Hao Weiguo, Li Yizhou, Tao Han, Susan Hares, Durrani, 2014-05-04, 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. "Using GOST 28147-89 with IPsec Encapsulating Security Payload (ESP)", Serguei Leontiev, Dmitry Pichulin, Andrey Fedchenko, 2014-06-11, This document defines the usage of GOST 28147-89 algorithm when providing data integrity and confidentiality in ESP protocol. The contents of this document is technically equivalent to its TC26 ROSSTANDART specification. This specification is maintained by TC26 ROSSTANDART and further updates are available at: http://www.tc26.ru/. "JSON Activity Streams 2.0 - Action Handlers", James Snell, Matthew Marum, 2014-05-13, This specification defines Action Handlers for use with the Activity Streams 2.0 format. "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, Yuji Kamite, Zafar Ali, 2014-06-06, 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. [I-D.ietf-pce-stateful-pce-app] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE. [I-D.ietf-pce-stateful-pce] provides the fundamental PCE communication Protocol (PCEP) extensions needed to support stateful PCE functions. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in supporting point-to-multipoint (P2MP) TE LSPs. "PCEP Extensions for Supporting Multiple Sources and Destinations", Udayasree Palle, Dhruv Dhody, 2014-02-13, 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 provides extensions for the Path Computation Element Protocol (PCEP) to support multiple sources and destinations in a single path request. "EST Extensions", Sean Turner, 2014-04-30, The EST (Enrollment over Secure Transport) protocol defined a Well- Known URI (Uniform Resource Identifier): /.well-known/est. EST also defined several path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). In some sense, the services provided by the path components can be thought of as PKI management-related packages. There are additional PKI-related packages a client might need as well as other security-related packages, such as firmware, trust anchors, and symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. "security architecture for 6top: requirements and structure", Michael Richardson, 2014-04-28, This document details security requirements for 6tisch nodes that use 6top in an industrial settings. Layer-2 and a layer-4 authentication and authorization requirements and assumptions are identified. Two approaches to accomplishing these requirements are outlined, with the goal of eventually picking one. This internet-draft is intended for later inclusion into the 6tisch architecture document. "Generic Fault-avoidance Routing Protocol for Data Center Networks", Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, 2014-06-21, 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. "Tagging Customer Bridge Domains in VPLS", Mingui Zhang, Bin Wang, Liang Xia, Jie Hu, 2014-02-14, This document proposes to use Customer VLAN ID as a identifier for traffic isolation in Virtual Private LAN Service (VPLS). In this way, multiple bridge domains of customers can share a single VPLS instance while their traffic are separated. With this proposal, Service Providers can be relieved from the heavy provisioning overhead of large number of pseudowires in the environment where a mass of bridge domains need be connected. "Transmission of IPv6 Packets over AERO Links", Fred Templin, 2014-06-09, This document specifies the operation of IPv6 over tunnel virtual Non-Broadcast, Multiple Access (NBMA) 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 IPv6 routing. Admission control and provisioning are supported by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), and node mobility is naturally supported through dynamic neighbor cache updates. "Generic UDP Encapsulation", Tom Herbert, 2014-03-04, 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, can be constructed. "Yang Data Model for Service Function Chaining", Reinaldo Penno, Paul Quinn, 2014-06-15, This document defines a YANG data model that can be used to configure and manage Service Function Chains. "The NULL Authentication Method in IKEv2 Protocol", Valery Smyslov, 2014-03-03, This document defines the NULL Authentication Method for the IKEv2 Protocol. This method provides a way to omit peer authentication in IKEv2 and to explicitely indicate it in the protocol run. This method may be used to preserve anonymity or in situations, where no trust relationship exists between the parties. "Advertising Global Labels or SIDs Using IS-IS", Xiaohu Xu, Mach Chen, 2013-12-24, Segment Routing (SR) is a new MPLS paradigm in which each SR-capable router is required to advertise global MPLS labels or Segment IDs (SID ) for its attached prefixes by using link-state IGPs, e.g., IS- IS. One major challenge associated with such global MPLS label or SID advertisement mechanism is how to avoid a given global MPLS label or SID from being allocated by different routers to different prefixes. Although such global label or SID allocation collision problem can be addressed through manual allocation , it is error- prone and nonautomatic therefore may not be suitable in large-scale SR network environments. This document proposes an alternative approach for allocating and advertising global MPLS labels or SIDs via IS-IS so as to eliminate the potential risk of label allocation collision. "DHCPv6/SLAAC Interaction Operational Guidance", Bing Liu, Ron Bonica, Tianle Yang, 2014-02-14, ND and DHCPv6 protocols could have some interaction on address provisioning with the A, M, and O flags defined in ND protocol. But the relevant standard definitions of the flags contain ambiguity, so that current implementations in operating systems have varied on interpreting the flags. The variation might impact real network operations, so this document aims to provide some operational guidance to eliminate the impact as much as possible. "Passive DNS - Common Output Format", Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern, 2014-03-03, This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. "An IP option for describing the traffic flow", Robert Chodorek, 2014-06-25, 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. "VPN Address Prefix Based Outbound Route Filter for BGP-4", Xiaohu Xu, 2013-12-27, This document defines a new Outbound Router Filter (ORF) type for BGP, refered to as "VPN Address Prefix Outbound Route Filter", that can be used to perform VPN 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 VPN address families. The VPN Address Prefix ORF is applicable in the context of Virtual Subnet and may also be applicable in other BGP/MPLS IP VPN environments. "SAML Profile for the Metadata Query Protocol", Ian Young, 2014-04-22, 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. "NFV High-Availability Technologies Gap Analysis", Yang Wang, 2013-12-30, High-Availability (HA) is a very important requirement throughout the history of carrier network, many technologies have emerged for it. With the trend of Network Function Virtualization (NFV), network function are migrated from dedicated hardware to software running over COTS servers, the same SLA of HA should be provided depending on network service itself. But some new challenges are brought by NFV, one example is Virtualized Network Function (VNF) cluster caused by the HA and performance limitation of individual VNF instance. For the VNF cluster, some gaps exist between with the available HA technologies on issues of multi-homing, state synchronization, share- risk prevention and HA role election, especially in the network which has a large scale deployment of NFV. This document firstly identifies the challenges emerged within NFV deployed networks. Then, available HA technologies are reviewed and the detailed gap analysis between them with the new challenges is discussed in depth. At last, the summary of these gaps is presented. "DS-lite security", Will, Fernando Gont, Tina Tsou, 2013-12-31, More and more operators have deployed or are about to deploy IPv6 transition technologies such as DS-lite, MAP, LAFT6, etc. The fundamental elements of these technologies are Network Address Translation (NAT) and Tunneling. The elements of these transition technologies may be subject to a number of attacks, unless appropriate mitigations are in place. This memo discusses the security implications of the aforementioned points, and additionally, provides a number of operational mitigations that could be deployed against these attacks. "Email Exchange of Secondary School Transcripts", James Davin, 2014-01-01, 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.", Bert Greevenbosch, 2014-02-14, This document proposes a notational convention to express CBOR data structures. Its main goal is to make it easy to express message structures for protocols that use CBOR. "TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records", oej, 2014-01-09, Use of TLS in the SIP protocol is defined in multiple documents, starting with RFC 3261. The actual verification that happens when setting up a SIP TLS connection to a SIP server based on a SIP URI is described in detail in RFC 5922 - SIP Domain Certificates. In this document, an alternative method is defined, using DNS-Based Authentication of Named Entities (DANE). By looking up TLSA DNS records and using DNSsec protection of the required queries, including lookups for NAPTR and SRV records, a SIP Client can verify the identity of the TLS SIP server in a different way, matching on the SRV host name in the X.509 PKIX certificate instead of the SIP domain. This provides more scalability in hosting solutions and make it easier to use standard CA certificates (if needed at all). "Framework for Abstraction and Control of Transport Networks", Daniele Ceccarelli, Luyuan Fang, Young Lee, Diego Lopez, 2014-05-30, This draft provides a framework for abstraction and control of transport networks. "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, 2014-01-03, Segment Routing architecture leverages the source routing and tunneling paradigm and can be directly applied to MPLS dataplane. 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 dataplane. "HTTP/2 Stream Dependencies", Michael Piatek, William Chan, 2014-01-06, The existing HTTP/2 prioritization scheme relies purely on integer values to indicate priorities. This simple scheme misses critical support for priority grouping, and does not support other features like resource ordering. This draft proposes using stream dependencies to solve the lack of priority grouping, as well as provide other features. "Side-channel considerations for cryptographic implementors.", Watson Ladd, 2014-01-06, This Internet-Draft explains what side-channels are, how implementors should avoid them, and how authors of standards should make it easy for implementors to avoid them. "Pervasive Attack: A Threat Model and Problem Statement", Richard Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie, 2014-01-06, Documents published in 2013 have revealed several classes of "pervasive" attack on Internet communications. In this document, we review the main attacks that have been published, and develop a threat model that describes these pervasive attacks. Based on this threat model, we discuss the techniques that can be employed in Internet protocol design to increase the protocols robustness to pervasive attacks. "Cross-domain Access Control in Low Power and Lossy Networks", De-Yun Gao, 2014-01-06, Access control is one of the major security concerns for Low power and Lossy Networks (LLN). As LLNs are normally highly distributed and resource-constrained, conventional access control systems that rely on the central Certificate Authority (CA) and sophisticated cryptographic algorithms are not suitable for them. Furthermore, LLNs may consist of embedded devices with limited power, memory, and processing resources from different manufacturers or service providers. Due to the different specifications and designs, it is difficult to ensure consistency in security implementation among all devices. This document proposes a distributed access control method based on local authorization decisions, which takes both the single- domain and the multi-domain situation into account. "Deterministic Forwarding PHB", Shitanshu Shah, Pascal Thubert, 2014-03-03, 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, 2014-04-15, 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 six domain name labels for special use in accordance with the criteria and procedures of [RFC6761]: localdomain, domain, lan, 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. "An Origin Attribute for the STUN Protocol", Alan Johnston, Justin Uberti, John Yoakum, Kundan Singh, 2014-03-31, STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. 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 and SIP contexts. "Additional Elliptic Curves for IETF protocols", Watson Ladd, 2014-03-28, This Internet Draft explains the mathematics behind and the parameters of a new family of elliptic curves with efficiency and security advantages over existing and widely deployed mechanisms. "The GeoJSON Format", H. Butler, M. Daly, A. Doyle, Sean Gillies, Stefan Drees, 2014-05-21, 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. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael Richardson, Sheng Jiang, Ted Lemon, 2014-05-19, The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be used separately or concurrently with the latter to obtain configuration parameters. "Opportunistic Encryption in MPLS Networks", Adrian Farrel, Stephen Farrell, 2014-02-10, This document describes a way to apply opportunistic encryption between adjacent nodes on an MPLS Label Switched Path (LSP) or between end points of an LSP. It explains how keys may be exchanged to enable the encryption, and indicates how key identifiers are exchanged in encrypted MPLS packets. Finally, this document describes the applicability of opportunistic encryption 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 de Dios, Daniele Ceccarelli, Bin-Yeong Yoon, 2014-05-27, 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, 2014-02-11, Elliptic curves with pairing are useful tools for constructing cryptographic primitives. In this memo, we specify domain parameters of Barreto-Naehrig curve (BN-curve) [5]. 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 two 254-bit BN-curves [1] [2] which allow us to obtain efficient implementations and domain parameters of 224, 256, 384, and 512-bit BN-curves which are compliant with ISO/IEC 15946-5[3]. Furthermore, this memo organizes differences between types of elliptic curves specified in ISO document and often used in open source softwares, which are called M-type and D-type respectively[21]. "Anchor-based Voronoi Routing Protocol", Wei Gong, Ke Tian, Baoxian Zhang, Kui Huang, 2014-01-10, The Anchor-based Voronoi Routing Protocol in this draft is an efficient distributed routing protocol for wireless sensor networks with mobile sinks. The design objective of the protocol is to reduce the overall updating overhead caused by the movement of mobile sinks and simultaneously build efficient data delivery structure. The basic idea behind AVRP is to combine the ideas of Voronoi scoping and dynamic anchor node selection. The designed protocol is simple, efficient, and easy to implement in dynamic wireless sensor networks with mobile sinks. "Explicit Trusted Proxy in HTTP/2.0", Salvatore Loreto, John Mattsson, Robert Skog, Hans Spaak, Dan Druta, Mohammad Hafeez, 2014-02-14, The purpose of this Internet Draft is to continue the discussion on explicit and trusted proxy as intermediary of HTTP2 traffic. The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or without TLS, without any constraints from the standard (see: issue 314). To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport "http" URIs resources: h2clr. This document describes two alternative methods for an user-agent to automatically discover and for an user to provide consent for a Trusted Proxy to be securely involved when he or she is requesting an HTTP URI resource over HTTP2 with TLS. The consent is supposed to be per network access. The draft also describes the role of the Trusted Proxy in helping the user to fetch HTTP URIs resource when the user has provided consent to the Trusted Proxy to be involved. "Experimental Option for TCP Host Identification", Brandon Williams, Mohamed Boucadair, Dan Wing, 2014-04-30, 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. "Architectural Approaches for Enhancing Email", Murray Kucherawy, 2014-04-25, This document provides guidance regarding architectural decisions made when developing enhancements to the Internet message service ("email"). "Triggering ND Address Resolution on Receiving DAD-NS", Ing-Wher Chen, Joel Halpern, 2014-01-10, This draft proposes a new optional event to trigger address resolution using IPv6 Neighbor Discovery. This helps optimize router performance, and can help mitigate certain potential ND-related denial-of-service attacks. Upon receiving a DAD-NS message, the neighbor solicitation message used to detect duplicate addresses, if the target address encoded in the DAD-NS is not a duplicate address, the receiving device responds by triggering address resolution for the target address in the DAD-NS, in preparation for expectant future communication with the sending device. "The Session Initiation Protocol (SIP) Digest Authentication Scheme", Rifaat Shekh-Yusef, 2014-01-25, This document updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm. "Captive-Portal identification in DHCP / RA", Warren Kumari, Olafur Gudmundsson, Paul Ebersman, Steve Sheng, 2014-06-02, In many environments (such as hotels, coffee shops and other establishments that offer Internet service to customers), it is common to start new connections in a captive portal mode, i.e. highly restrict what the customer can do until the customer has accepted terms of service, provided payment information or authenticated. This document describes a DHCP option (and an 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. "Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks", Behcet Sarikaya, Frank Xia, 2014-01-14, Modifications to 6lowpan Neighbor Discovery protocol are proposed in order to secure the neighbor discovery for low-power and lossy networks. This document defines lightweight and secure version of the neighbor discovery for low-power and lossy networks. The nodes generate a Cryptographically Generated Address, register the Cryptographically Generated Address with a default router and periodically refresh the registration. Cryptographically generated address and digital signatures are calculated using elliptic curve cryptography, so that the cryptographic operations are suitable for low power devices. "The 'publish' Link Relation Type", Erlend Hamnaberg, 2014-01-17, This memo defines a 'publish' link relation and provides a number of examples. "Bootstrapping Key Infrastructures", Max Pritikin, Michael Behringer, Steinthor Bjarnason, 2014-01-15, This document specifies automated bootstrapping of an key infrastructure using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based cloud service. Before being authenticated, a new device has only link- local connectivity, and does not require a routable address. When a vendor cloud service is provided devices can be forced to join only specific domains but for contrained environments we describe a variety of options that allow bootstrapping to proceed. "Making The Internet Secure By Default", Michael Behringer, Max Pritikin, Steinthor Bjarnason, 2014-01-15, Pervasive monitoring on the Internet is enabled by the lack of general, fundamental security. In his presentation at the 88th IETF Bruce Schneier called for ubiquitous use of security technologies to make pervasive monitoring too expensive and thus impractical. However, today security is too operationally expensive, and thus only used where strictly required. In this position paper we argue that all network transactions can be secure by default, with minimal or no operator involvement. This requires an autonomic approach where all devices in a domain enrol automatically in a trust domain. Once they share a common trust anchor they can secure communications between themselves, following a domain policy which is by default secure. The focus of this proposal is the network itself, with all protocols between network elements, including control plane protocols (e.g., routing protocols) and management plane protocols (e.g., SSH, netconf, etc). The proposal is evolutionary and allows a smooth migration from today's Internet technology, device by device. "STRINT Workshop Position Paper: Strengthening the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, alkemade, 2014-02-13, This document describes existing and potential future efforts at strengthening the Extensible Messaging and Presence Protocol (XMPP), for discussion at the W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT). "Federated Filesystem Security Addendum", Chuck Lever, 2014-01-15, This document addresses critical security-related items that are missing from existing FedFS proposed standards. "HTTP Redirect Codes for RESTful Services", Phil Hunt, 2014-01-15, This specification clarifies the use of HTTP redirect codes when used with RESTful services. "Linkability Considered Harmful", Leif Johansson, Linus Nordberg, 2014-01-21, Current debate on pervasive monitoring often focus on passive attacks on the protocol and transport layers but even if these issues were eliminated through the judicious use of encryption, roughly the same information would still be available to an attacker who is able to (legally or otherwise) obtain access to linked data sets which are being maintained by large content and service providers. "NVO3 Operations, Administration, and Maintenance Requirements", Peter Ashwood-Smith, Liang Xia, Ranga Iyengar, Tina Tsou, Ali Sajassi, Mohamed Boucadair, Christian Jacquenet, Masahiro Daikoku, Anoop Ghanwani, ramki, 2014-06-15, This document provides framework and requirements for Network Virtualization Overlay (NVO3) Operations, Administration, and Maintenance (OAM). This document for the most part gathers requirements from existing IETF drafts and RFCs which have already extensively studied this subject for different data planes and layering. As a result this draft is high level and broad. We begin to ask which are truly required for NVO3 and expect the list to be narrowed by the working group as subsequent versions of this draft are created. "Performance-based BGP Routing Mechanism", Xiaohu Xu, Hui Ni, Mohamed Boucadair, Christian Jacquenet, So Ning, Fan Yongbing, 2014-01-15, 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. "Erosion of the moral authority of middleboxes", Joe Hildebrand, 2014-01-15, Many middleboxes on the Internet attempt to add value to the connections that traverse that point on the network. Problems in their implementations erode the moral authority that otherwise might accrue to the legitimate value that they add. "STRINT Workshop Position Paper: Levels of Opportunistic Privacy Protection for Messaging-Oriented Architectures", Dave Crocker, Pete Resnick, 2014-01-15, Given a concern for pervasive monitoring, messaging information needing protection includes primary payload, descriptive meta-data, and traffic-related analysis. Complete protection against pervasive monitoring (PM), for traffic through complex handling sequences, has not yet been achieved reliably in real-world operation. Consequently, it is reasonable to consider a range of mechanisms, for protecting differing amounts of information and against monitoring of different kinds. Although channel-based encryption can be helpful, it is not sufficient. This paper considers pursuing different levels of end-to-end protection, referencing examples of component mechanisms that already have encouraging field experience. "Safe increase of the TCP's Initial Window Using Initial Spreading", Renaud Sallantin, Cedric Baudoin, Fabrice Arnal, Emmanuel Dubois, Emmanuel Chaput, Andre-Luc Beylot, 2014-03-13, This document proposes a new fast start-up mechanism for TCP that can be used to speed the beginning of an Internet connection and then improved 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 do not deteriorate long-lived TCP flows performance. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, 2014-01-16, 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. "An Authorization Information Format (AIF) for ACE", Carsten Bormann, 2014-01-17, 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. One potential work item is an Authorization Information Format (AIF). This document provides a strawman for such a format that is intended to enable further discussion of the objectives for its development. "Source-Group Tag eXchange Protocol (SXP)", Michael Smith, Rakesh Kandula, 2014-01-17, 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. "A Service Function Chaining Header and Forwarding Mechanism", Lehong Niu, Hongyu Li, Yuanlong Jiang, Lucy Yong, 2014-04-11, This document proposes a service function chain header and describes forwarding mechanism, including processing procedures for each component in a generic service function chain. "Email archival services supported by may be archive.org", pradeep xplorer, 2014-01-18, 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. "Clarifying RPKI use of CMS SignerInfo"", George Michaelson, Geoff Huston, 2014-02-07, RFC6485 section 2 mandated a single CMS OID sha256withRSAEncryption from RFC4055 for use in the CMS SignerInfo field. This draft updates RFC6485 and extends it to permit the correct CMS use which includes an option of rsaEncryption for the SignerInfo field. "EPP Registrant Security Problem Statement", Patrik Wallstrom, 2014-01-20, This document collects a number of requirements on securing the provisioning of DNS data between a Registrant and a Registry. The most common attack in the chain of Registrant-Registrar-Registry is to inject false information into the Registrar system, which in turn forwards the injected data to the Registry using EPP, the Extensible Provisioning Protocol. "Advertising Global Labels or SIDs Using OSPF", Xiaohu Xu, Mach Chen, 2014-01-20, Segment Routing (SR) is a new MPLS paradigm in which each SR-capable router is required to advertise global MPLS labels or Segment IDs (SID) for its attached prefixes by using link-state IGPs, e.g., OSPF. One major challenge associated with such global MPLS label or SID advertisement mechanism is how to avoid a given global MPLS label or SID from being allocated by different routers to different prefixes. Although such global label or SID allocation collision problem can be addressed through manual allocation , it is error-prone and nonautomatic therefore may not be suitable in large-scale SR network environments. This document proposes an alternative approach for allocating and advertising global MPLS labels or SIDs via OSPF so as to eliminate the potential risk of label allocation collision. "ChaCha20, Poly1305 and their use in IPsec", Yoav Nir, 2014-06-01, This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for IPsec. "Use Cases for Resource Pools with Virtual Network Functions (VNFs)", Susan Hares, 2014-02-13, In the context of virtualization, a service essentially consists of a set of Virtualized Network Functions (VNFs) with each VNF building on top of virtualization infrastructure to implement a specific network functions along with the data connections between VNFs. VNFs may be highly distributed existing in devices in data center networks, mobile networks or satellite networks. In some of these environments, the resources are highly constrained. This draft provides seven use cases the author has observed in demonstrations or deployments for the following network function virtualization: cloud bursting, parental controls, load balancer for multipath (L1-L7), WAN optimization that runs either between access nodes and Data Centers, WAN optimization between mobile phones and Data Centers (through access nodes), application placement optimization, and optimized placement of web applications utilizing minimal data transfer. "IODEF extension for Reporting Cyber-Physical System Incidents", murillo@ieee.org, 2014-01-22, This draft document will extend the Incident Object Description Exchange Format (IODEF) defined in [RFC5070] to support the reporting of incidents dealing with attacks to physical infrastructure through the utilization of IT means as a vehicle or as a tool. These systems might also be referred as Cyber-Physical Systems (CPS), Operational Technology Systems, Industrial Control Systems, Automatic Control Systems, or simply Control Systems. These names are used interchangeably in this document. In this context, an incident is generally the result of a cybersecurity issue whose main goal is to affect the operation of a CPS. It is considered that any unauthorized alteration of the operation is always malign. This extension will provide the capability of embedding structured information, such as identifier- and XML-based information. In its current state, this document provides important considerations for further work in implementing Cyber-Physical System incident reports, either by utilizing any already existing industry formats (XML- encoded) and/or by utilizing atomic data. In addition, this document should provide appropriate material for helping making due considerations in making an appropriate decision on how a CPS reporting is done: 1) through a data format extension to the Incident Object Description Exchange Format [RFC5070], 2) forming part of an already existing IODEF-extension for structured cybersecurity information (currently draft draft-ietf-mile-sci-11.txt), or others. While the format and contents of the present document fit more the earlier option, these can also be incorporated to the later. "Additional Elliptic Curves for Transport Layer Security (TLS) Key Agreement", Simon Josefsson, Manuel Pégourié-Gonnard, 2014-01-22, This document specifies the use of additional elliptic curves (E382, M383, Curve3617, M511, E521) for key exchange in the Transport Layer Security (TLS) protocol. "Requirements for Labels to Interoperate Between mDNS and DNS", Andrew Sullivan, 2014-01-22, Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Different name systems use different conventions for the characters allowed in any name. In order for DNS-SD to be used effectively in environments where multiple different name systems are in use, it is important to follow a common set of conventions for naming. This memo presents an outline of the reqiurements for selection of labels for mDNS and DNS when they are expected to interoperate in this manner. "Customizable Network Abstract Interface (NAI) Architecture based on Model Description", Yinben Xia, Sheng Jiang, Xuewei Wang, 2014-01-22, The more and more complicated ISP networks are required a new interaction mechanism between their customers and their networks. A flexible Network Abstract Interface (NAI) is needed to provide abstracted network information and capability to network customers and receive customized orders from them. This document introduces an architecture that allows network administrators to create their specific Network Abstract Interface. "Solutions for Marking SIP Messages to be Logged", Peter Dawes, 2014-01-22, SIP networks use signalling monitoring tools to diagnose user reported problem 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 draft describes potential solutions to meet 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 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. "Address Prefix Based VPN Route Distribution Constrain", Xiaohu Xu, Mach Chen, 2014-01-23, This document defines MP-BGP procedures that allow BGP speakers to exchange VPN route interest information. This information can be used to control VPN route distribution at the granularity of address prefix, which is applicable in the context of Virtual Subnet and may also be applicable in other BGP/MPLS IP VPN environments. "VPN Address Prefix Based Outbound Route Filter for BGP-4", Xiaohu Xu, 2014-01-23, This document defines a new Outbound Router Filter (ORF) type for BGP, refered to as "VPN Address Prefix Outbound Route Filter", that can be used to perform VPN 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 VPN address families. The VPN Address Prefix ORF is applicable in the context of Virtual Subnet and may also be applicable in other BGP/MPLS IP VPN environments. "Network Smart Tapping (SmarTap)", Youval Nachum, Linda Dunbar, Tal Mizrahi, 2014-01-23, Tapping technologies provide traffic visibility to network analysis tools such as monitors, traffic recorders and security systems. Current tapping architectures and protocols are vendor specific and adapted to legacy networks. Emerging networking such as large scale datacenters for cloud applications and Mobile backhaul networks demand accurate and fast network traffic visibility. These networks are built on Layer 2 technologies and infrastructure to support virtual machines mobility, growing number of devices including mobile users. SmarTap architecture is designed to support emerging network requirements allowing network analysis tools to gain full visibility of network traffic. SmarTap technology monitors each link and each component of the network. It captures packets, classifies them and sends them to tools with relevant packet attributes. SmarTap can provide attributes such as flow-ID, tapping-location, tapping-time and statistics. "Requirements for Very Fast Setup of GMPLS LSPs", Andy Malis, Ronald Skoog, Haim Kobrinski, George Clapp, John Drake, Vishnu Shukla, 2014-02-12, The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program has laid out a vision for the next evolution of IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks. It anticipates the need for rapid (sub-second) setup and SONET/SDH- like restoration times for high-churn (up to tens of requests per second network-wide and one second to one minute holding times) on- demand wavelength, sub-wavelength and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call blocking requirements, and while minimizing the use of resources such as time slots, switch ports, wavelength conversion and wavelength-km. This document discusses the requirements for extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for expediting the control of Label Switched Paths (LSPs), including sub- wavelengths (e.g., OTN ODUs) and full wavelengths, in order to satisfy application requirements laid out in this program. ""Dotless Domains", Confusion, and DNS Terminology", John Klensin, 2014-01-23, The history of the DNS has included a great deal of confusion about terminology that has, in turn, led to discussions in which different parties have used the same words for different things. For example, "host name" has been used to describe both fully-qualified domain names with particular properties and the first label component of such names. While established inconsistent uses may be impossible to correct, it is in the interest of the community to avoid increasing the confusion. There have recently been a number of discussions about "dotless domains" with at least four different definitions used or implied in different contexts. This document explains those uses and recommends avoiding the use of the term. "Applying Unauthenticated Transport Layer Security (TLS) to Hypertext Transport Protocol (HTTP) Connections", Matthew Miller, 2014-01-23, With the pervasiveness of passive monitoring and ubiquity of unencrypted Hypertext Transport Protocol (HTTP), it is desirable to mitigate passive monitoring without causing an undue burden on HTTP user agents and servers. This document describes the rationale and process for using Transport Layer Security (TLS) in an unauthenticated manner for exchanging HTTP messages. The application of unauthenticated TLS - particularly when Perfect Forward Secrecy (PFS) algorithms are used - change monitoring from being a passive attack into an active attack. "Network Abstract Interface (NAI) Modeling Language", Yinben Xia, Sheng Jiang, Xuewei Wang, Bing Liu, 2014-01-24, This document introduces a modeling language used to model network services by network operators and customers to create specific network service instances through the standardized Network Abstract Interface (NAI) and processed automatically by the network. "Usage of NTP for the PDM DOH IPv6 Extension Header", Michael Ackermann, Nalini Elkins, William Jouris, Keven Haining, 2014-01-24, The Performance and Diagnostic Metrics (PDM) Destination Options Header (DOH) for IPv6 defines metrics which are critical for timely end-to-end problem resolution, without impacting an operational production network. These metrics and their derivations can be used for network diagnostics. The base metrics are: packet sequence number and packet timestamp. The timestamp fields require time synchronization at the two end points. This document provides implementation guidelines for implementing Network Time Protocol (NTP) to provide such synchronization. "PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model", Udayasree Palle, Dhruv Dhody, Yosuke Tanaka, Yuji Kamite, Zafar Ali, 2014-06-06, 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. The extensions described in [I-D.ietf-pce-stateful-pce] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCE communication Protocol (PCEP), for a model where the Path Computation Client (PCC) delegates control over one or more locally configured LSPs to the PCE. Further [I-D.ietf-pce-pce-initiated-lsp] describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. 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. "CLUE and latent configurations", Christian Groves, Weiwei Yang, Roni Even, 2014-01-26, This document proposes to use Latent Configurations as described by the SDP media capability negotiation framework [RFC6871] for the description and negotiation of CLUE encodings. "Endpoint and PID Property Extension for virtualized endpoint and infrastructure", Qin Wu, Zehn Cao, 2014-01-27, This document extends the Application-Layer Traffic Optimization (ALTO) protocol [I-D.ietf-alto-protocol] and Proposes additional new Endpoint properties and PID properties for virtualized endpoint and infrastructure. "OSPFv3 over IPv4 for IPv6 Transition", Ing-Wher Chen, Acee Lindem, 2014-01-27, This draft 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 simplifies transition from an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain, and later possibly to an IPv6-only routing domain. "ChaCha20 and Poly1305 for IETF protocols", Yoav Nir, Adam Langley, 2014-06-19, This document defines the ChaCha20 stream cipher, as well as the use of the Poly1305 authenticator, both as stand-alone algorithms, and as a "combined mode", or Authenticated Encryption with Additional Data (AEAD) algorithm. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. "A YANG Data Model for NETCONF Server Configuration", Kent Watsen, Jürgen Schönwälder, 2014-02-14, This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. "The 'XML2RFC' version 3 Vocabulary", Paul Hoffman, 2014-05-14, 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-reschke-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, 2014-02-14, 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, 2014-06-25, 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. "An Information Model for Network policy", Susan Hares, Wenson Wu, 2014-03-03, This document introduces an information model for network policies. This model operates as policy model that can be linked to other information model such as the I2RS RIB information model. Some applications that utilize the services of I2RS client may require specific set of data in response to network events or conditions based on pre-established rules. In order to reduce the data flow through the network, the I2RS client needs to signal the I2RS agent to filter some of the collected data or events prior to transmission, or group the data prior to transmission to the i2rs client. This functionality is necessary to meet the requirements i2rs enabled services which include service-layer routing improvements, and control of traffic flows and exit points. The information model is based on extensible information model for representing policies, for example, the Policy Core Information Model (PCIM) (RFC3060), and an extension to this model to address the need for QoS management, called the Quality of Service (QoS) Policy Information Model (QPIM)(RFC3644) and policy based routing. "PCEP Extensions for Receiving SRLG Information", Dhruv Dhody, Fatai Zhang, Xian Zhang, Victor Lopez, Oscar de Dios, 2014-02-10, 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 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. "Resource Certificate PKI (RPKI) Trust Anchor Locator", Geoff Huston, Samuel Weiler, George Michaelson, Stephen Kent, 2014-02-10, This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). "IPv6 Universal Extension Header", Fernando Gont, Will, Suresh Krishnan, Hagen Pfeifer, 2014-04-08, This document analyzes a problem in the Uniform Format for IPv6 Extension Headers specified in RFC 6564, which results in nodes not being able to process an IPv6 Header Chain if it contains an unrecognized IPv6 Extension Header that follows the aforementioned Uniform Format. It analyzes the implications of the aforementioned problem, and discusses a number of possible solutions, including the specification of a new IPv6 Extension Header - the Universal Extension Header - that overcomes the aforementioned issues. "LMA Coordination in a Dynamic LMA Environment", Qing Zhou, Sebastian Peters, Fikret Sivrikaya, Rute Sofia, 2014-01-31, This document describes local mobility anchor coordination functionality and corresponding mobility options for Proxy Mobile IPv6. The mobility anchor coordination targets LMAs with a dynamic service provisioning behavior, and is achieved by Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a Local Mobility Anchor (LMA) and a Local Mobility Anchor Coordinator (LMAc). "Diet-ESP: a flexible and compressed format for IPsec/ESP", Daniel Migault, Tobias Guggemos, Daniel Palomares, 2014-01-31, IPsec/ESP has been designed to secure IP packets exchanged between two nodes. IPsec implements security at the IP layer which makes security transparent to the applications, as opposed to TLS or DTLS that requires application to implement TLS/DTLS. As a result, IPsec enable to define the security rules in a similar way one establishes firewall rules. One of the IPsec's drawbacks is that implementing security on a per packet basis adds overhead to each IP packet. Considering IoT devices, the data transmitted over an IP packet is expected to be rather small, and the cost of sending extra bytes is so high that IPsec/ESP can hardly be used for IoT as it is currently defined in RFC 4303. This document defines Diet-ESP, a protocol that compress and reduce the ESP overhead of IPsec/ESP so that it can fit security and energy efficient IoT requirements. Diet-ESP use already existing mechanism like IKEv2 to negotiate the compression format. Furthermore a lot of information, already existing for an IPsec Security Association, are reused to offer light negotiation in addition to maximum compression. "Minimal ESP", Daniel Migault, Tobias Guggemos, Daniel Palomares, 2014-01-31, This document describes a minimal version of the IP Encapsulation Security Payload (ESP) described in RFC 4303 which is part of the IPsec suite. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document does not update or modify RFC 4303, but provides a compact description of the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. "Optimal Transmission Window Option for ICMPv6 Router Advertisement", Teemu Savolainen, 2014-01-31, For a class of gateways an activation of an uplink network connection, such as cellular radio connection, incurs a fixed cost in form of consumed energy. For these gateways minimizing the number of uplink activations is of importance. This specification describes an Optimal Transmission Window option for ICMPv6 Router Advertisement that a gateway can use to communicate optimal transmission window for nodes it is serving, thus helping to group separate transmissions together and thereby reduce number of gateway's uplink connection activation events. "BGP Auto Discovery", Robert Raszuk, Warren Kumari, Jon Mitchell, Keyur Patel, John Scudder, 2014-01-31, 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. "Opportunistic Encryption Using TLS", Paul Hoffman, 2014-02-02, This document defines the term "opportunistic encryption using TLS" as it applies to application protocols that use TLS. "Secure Hybrid Wireless Mesh Protocol (SHWMP)", Sang-Gon Lee, Mallikarjun Avula, Seong-Moo Yoo, 2014-03-13, Secure Hybrid Wireless Mesh Protocol (SHWMP) for a Wireless Mesh Network (WMN) is a modified version of Hybrid Wireless Mesh Protocol (HWMP) which ensures both end-to-end and point-to-point authentication and integrity by using ID based signature schemes and key agreement schemes. "The AutoVPN Architecture", Yaron Sheffer, Yoav Nir, 2014-02-03, This document describes the AutoVPN architecture. AutoVPN allows IPsec security associations to be set up with no prior configuration, using the "leap of faith" paradigm. The document defines a lightweight protocol for negotiating such opportunistic encryption either directly between hosts or between two security gateways on the path. "Seamless Bidirectional Forwarding Detection (BFD) Use Case", Sam Aldrin, Manav Bhatia, Greg Mirsky, Nagendra Kumar, Satoru Matsushima, 2014-03-28, This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that simplified solution and extensions could be developed for detecting forwarding failures. "Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes", Markus Stenberg, 2014-06-19, 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. "RFC Style Guide", Heather Flanagan, 2014-04-09, This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style guide. Guidance provided by this document will not be applied until published as an RFC. Please send your comments about the contents of this document to . "Problem Statement for Abstraction and Control of Transport Networks", Young Lee, Daniel King, Mohamed Boucadair, Ruiquan Jing, Luis Contreras, 2014-06-03, Previously transport networks were typically static, lacked flexibility, and required 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 for meeting operator's requirement for their virtual network operation. Virtual network operation refers to the creation of a virtualized environment allowing operators to view the abstraction of the underlying multi-admin, multi-vendor, multi- technology networks and to operate, control and manage these multiple networks as single virtualized network. Another dimension of virtual network operation is associated with use of the common core transport network resource 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, scope of work, and outlines the core requirements to facilitate virtual network operation. "Transport Services Strawman Architecture", Marie-Jose Montpetit, Igor Zhovnirovsky, Bernd Reuther, 2014-02-11, This document presents one possible architecture to provide appropriate transport services to applications. It uses a shim layer between the application and the transports. The transport is chosen via the shim based on parameters that reflect the needs of the applications. "Why Network-Layer Multicast is Not Always Efficient At Datalink Layer", Eric Vyncke, Pascal Thubert, Eric Levy-Abegnoli, Andrew Yourtchenko, 2014-02-14, Several IETF protocols (IPv6 Neighbor Discovery for example) rely on IP multicast in the hope to be efficient with respect to available bandwidth and to avoid generating interrupts in the network nodes. On some datalink-layer network, for example IEEE 802.11 WiFi, this is not the case because of some limitations in the services offered by the datalink-layer network. This document lists and explains all the potential issues when using network-layer multicast over some datalink-layer networks. "Prefix and Address Assignment in a Home Network", Pierre Pfister, Benjamin Paterson, Jari Arkko, 2014-05-06, This memo describes a home network prefix and address assignment algorithm running on top of any 'flooding protocol' that fulfills the specified requirements. It is expected that home border routers are allocated one or multiple IPv6 prefixes through DHCPv6 Prefix Delegation (PD) or that prefixes are made available through other means. An IPv4 address can also be assigned and private addresses be used with NAT to provide IPv4 connectivity. In both cases, provided prefixes need to be efficiently divided among the multiple links and routers need to obtain addresses. This document describes a distributed algorithm for IPv4 and IPv6 prefixes division, assignment and router's address assignment, and specifies how hosts can be given addresses and configuration options using DHCP or SLAAC. "mDNS X-link review", Douglas Otis, 2014-04-22, 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, 2014-02-07, 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 get and set xattrs on file system objects. "AQM Evaluation Guidelines", N. Kuhn, Preethi Natarajan, David Ros, Naeem Khademi, 2014-06-18, 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), optionally in combination with a packet scheduling scheme such as fair queuing. The IETF AQM and packet scheduling working group was formed to standardize AQM schemes that are robust, easily implemented, and successfully deployed in today's networks. This document describes various criteria for performing precautionary evaluations of AQM proposals. This document also helps in ascertaining whether any given AQM proposal should be taken up for standardization by the AQM WG. "Software Defined Networking extensions for the Locator/ID Separation Protocol", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, sbarkai@gmail.com, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci, 2014-02-07, This document describes extensions for the Locator/ID Separation Protocol (LISP) to make it more suitable to be used on Software Defined Networking (SDN) scenarios. "ADD-PATH for Route Servers", Pierre Francois, Camilo Cardona, Adam Simpson, Jeffrey Haas, 2014-02-07, BGP speakers in Internet Exchange Points exchange routes with a large number of peers. To reduce the burden of maintaining many sessions, IXPs implement and administrate BGP route servers. Route servers announce to their clients the paths of multiple peers by using a single eBGP session. Route servers, however, are restricted to propagating a single path per NLRI per eBGP session. This constraint affects the path diversity received by clients, which could use paths that they would not have chosen, had they known all possible paths. To overcome this limitation, we propose in this draft the extension of ADD-PATH to eBGP peers in the context of route servers. "ADD-PATH limit capability", Pierre Francois, Camilo Cardona, Adam Simpson, Jeffrey Haas, 2014-02-07, In this draft, we propose a new capability that allows BGP speakers supporting ADD-PATH to announce a limit on the number of paths they want to receive from their peers. "Contextualized Information-Centric Home Networking", Ravi Ravindran, Asit Chakraborti, Guoqiang Wang, 2014-02-13, Home network (Homenet) is a good application scenario for ICN considering it is a point where diverse users, devices, applications, and services meet. Homenets are getting increasingly complex with the presence of application specific sensors, smart appliances, and smart networking devices such as residential gateway. Home automation today is being driven by several alliances such as DLNA, AllJoyn, ZigBee, and Z-Wave aimed at supporting homenet services such as multimedia sharing, lighting control, climate control, and energy management. These standards overlay application semantics over a host centric architectures which is inefficient, and the lack of inter-operability among these standards results in high cost, inflexibility, and management issues. Homenet is an information- centric environment where the objective is to enable consumers and producers to interact in a contextual manner independent of their underlying topology arrangement. Although the overall homenet objectives over an ICN framework versus any other are the same; ICN can distinguish itself by providing a rich service abstraction layer applicable in local scale as in BAN/PAN/LAN, and also enable intelligent interaction beyond the homenet boundary. In this draft we share the idea of a contextualized information- centric bus (CIBUS) which builds on ICN abstractions of naming, name resolution, and content dissemination for home network by providing support for service management, context processing and monitoring, policy management, and policy based routing and forwarding. CIBUS allows applications and services to discover each other, subscribe/ notify to event upon which service composition can be realized locally or in a centralize manner. Furthermore, service policies can be applied at high granularity which can be imposed in the routing and forwarding plane through ICN extensions. Some of these CIBUS features that were realized in [5] is presented here. "Connecting SPRING Islands over IP Networks", Xiaohu Xu, Siva Sivabalan, 2014-02-07, Segment Routing (SR) architecture [SR-ARCH] introduces a new MPLS paradigm in which a sender of a packet is allowed to partially or completely specify the route the packet takes through the network by using stacked MPLS labels. The current SR architecture requires an end-to-end MPLS Label Switched Path (LSP) between any two SR-enabled routers (e.g., two adjacent hops of a given explicit path). In order to enable SR to be deployed even when there are non-MPLS routers along the path between two SR-enabled routers, it is desirable to have an alternative, which allows the use of IP-based tunnels (e.g., GRE tunnels) to connect two SR-enabled routers. This document describes a mechanism for such usage. "Cooperating Layered Architecture for SDN", Luis Contreras, Carlos Bernardos, 2014-02-08, The Software Defined Networking paradigm proposes the separation of the control plane from the data plane in the network nodes and its logical centralization on a control entity. All the network intelligence is moved to this central entity. Typically, such central 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 services and transport control. This document describes a new 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 evolutionary way. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Sergio Murillo, 2014-02-09, 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. This document normatively updates [I-D.draft-ietf- bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] "Validating Info/Query (IQ) stanzas in the Extensible Messaging and Presence Protocol (XMPP)", alkemade, 2014-02-09, This document provides security recommendations for the validation and generation of Info/Query (IQ) stanzas in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120. "SFC Service Decomposition", Kevin Ma, Ron Parker, 2014-02-13, This document discusses the role of composite (monolithic) service functions in service function chaining, and describes a method for supporting composite service function decomposition. "IGP extension for PCEP security capability support in the PCE discovery", Diego Lopez, Qin Wu, Dhruv Dhody, Daniel King, 2014-02-10, 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. [RFC5088] and [RFC5089] define a method to advertise path computation capabilities using IGP flooding for OSPF and ISIS respectively. However [RFC5088] and [RFC5089] lacks 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 (defined in [RFC5088] and [RFC5089]) to distribute PCEP security support information. "RFCs and the "Historical" Category", John Klensin, Scott Bradner, 2014-02-14, The "Historical" category has been used to identify some documents in the RFC Series for many years, but has never been precisely defined except in various oral traditions. More important, with one exception that is now obsolete, the conditions under which documents should be reclassified as Historic and the procedures for doing so have never been defined, leading to a number of ad hoc and inconsistent actions. This document clarifies both the category and procedures for putting documents into it. "A Configuration File Format for Extensible Authentication Protocol (EAP) Deployments", Stefan Winter, 2014-02-10, This document specifies a file format 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, 2014-06-26, 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. Further this document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate Service Function Paths (SFP). "IETF ForCES Logical Function Block (LFB) Subsidiary Management", Bhumip Khasnabish, Evangelos Haleplidis, Jamal Hadi Salim, 2014-02-10, This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Forwarding Element (FE). "Cloud of Secure Elements(CoSE)", Pascal Urien, 2014-02-10, 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. "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan, 2014-04-16, This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice / guidance to developers developing alternate namespaces. "Quality of Service Marking in Virtual eXtensible Local Area Network", Behcet Sarikaya, Frank Xia, 2014-02-10, The Virtual eXtensible Local Area Network enables multiple tenants to operate in a data center. Each tenant needs to be assigned a priority group to prioritize their traffic. Cloud carriers wish to use quality of service to differentiate different applications. For these purposes, three bits are assigned in the eXtensible Local Area Network header. How these bits are assigned and are processed in the network are explained in detail. "IPv6 RA Options for Next Hop Routes", Behcet Sarikaya, 2014-06-03, This document proposes new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. Using these options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. Each option is defined together with definitions of host and router behaviors. This document also proposes the router advertisement extensions for source address dependent routing. "Simplified Local internet nUmber Resource Management with the RPKI", David Mandelberg, 2014-02-10, 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. Internet Service Providers (ISPs) can use the RPKI to validate BGP route origination assertions. 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. "TURN Server Auto Discovery", Prashanth Patil, Tirumaleswar Reddy, Dan Wing, 2014-05-02, 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 or the ISP, 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 two such mechanisms for TURN server discovery. "Formal Verification for Software-Defined Networks (SDN)", Myung-Ki Shin, Seungik Lee, 2014-02-11, To design and implement networks that conform to the design goals of SDN network topology, the structure and behavior of the networks need to be formally verified to prevent from misinterpreting of the intended meanings and to avoid inconsistency in the networks. This document discusses basic requirements, framework, and case studies of formal verification for SDN. "ACE use cases", Ludwig Seitz, Stefanie Gerdes, Goran Selander, 2014-02-11, This document presents use cases for authentication and access control in scenarios involving constrained RESTful devices. Where specific details are relevant, it is assumed that the devices use CoAP as communication protocol, however most conclusions apply generally. A number of security requirements are derived from the use cases, which are intended as a guideline for developing a comprehensive authentication and access control approach for this class of scenarios. "A generic control stream for Multipath TCP", Christoph Paasch, Olivier Bonaventure, 2014-02-11, Multipath TCP's extensive use of TCP options to exchange control information consumes a significant part of the TCP option space. Extending MPTCP to add more control information into the session becomes cumbersome as the TCP option space is limited to 40 bytes. This draft introduces a control stream that allows to send control information as part of the subflow's payload. The control stream is mapped into a separate sequence number space and uses a TLV-format for maximum extensibility. It is left to future documents to specify how the TLV-format might be used to exchange control information. As the control stream is sent as part of the subflow's payload, it is not subject to the 40 bytes limitation of the TCP option space. "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2014-02-11, This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. "IPv6 mapping to non-IP protocols", Gianluca Rizzo, Antonio Jara, Alex Olivieri, Yann Bocchi, Maria Palattella, Latif Ladid, 2014-02-11, 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. Many of those devices presently are based on networking technologies other than IP. In order to include them into an IPv6 based Internet of Things, a mechanism for assigning an IPv6 address to each of them is required. The only existing proposal for a standard way of assigning an IPv6 address to devices which do not support IPv6 or IPv4, is very generic, it leaves many problems unsolved and it is nowadays inadequate to cope with the new scenarios opened by the Internet of Things. 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 to interconnect through the Internet and to fully integrate into a world wide scale IPv6 IoT. "Plasma Protected IODEF", Jim Schaad, 2014-02-11, The Incident Object Description Exchange Format (IODEF) defines a XML representation for information about computer security incidents. The driver for the standardization effort for IODEF is the desire to share the information as part of the cybersecurity response. As the security considerations of RFC5070 notes, the data can be sensitive and should only be disclosed to appropriate parties. This document describes how to use the Plasma policy enforcement model to ensure access to the IODEF data follows the appropriate policies in a distributed environment and independent of the transports used to share the information. "MILE Implementation Report", Kathleen Moriarty, 2014-02-11, 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. "NVO3 Fault Management", Tissa Senevirathne, Norman Finn, Samer Salam, Deepak Kumar, Donald Eastlake, Sam Aldrin, 2014-02-11, 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, 2014-04-09, Network Coding is a technique used to code packets and be able to recover coded packets from loses. It requires atleast 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, 2014-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. "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel, 2014-05-07, 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 15 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. "IKEv2/IPsec Context Definition", Daniel Palomares, Daniel Migault, 2014-03-05, IKEv2/IPsec clusters are constituted of multiple nodes accessed via a single address by the end user. The traffic is then split between the nodes via specific IP load balancing policies. Once a session is assigned to a given node, IPsec makes it difficult to assign the session to another node. This makes management operations and transparent high availability for end users difficult to perform within the cluster. This document describes the IKEv2 and IPsec contexts that MUST be transferred between nodes within a cluster so a session can be restored. This makes possible to transfer an IPsec session between different nodes. "BGP Link-State extensions for Segment Routing", Hannes Gredler, Saikat Ray, Stefano Previdi, Clarence Filsfils, Mach Chen, Jeff Tantsura, 2014-02-13, Segment Routing (SR) allows for a flexible definition of end-to-end paths within link-state graphs by encoding paths as sequences of topological sub-paths, called "segments". The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise the segments. But flooding based propagation of path segments using IGPs is limited by the perimeter of the IGP domain. For building paths which span across IGP domains (e.g. multiple ASes), the Border Gateway Protocol (BGP) is better suited as its propagation perimeter is not limited like the IGPs. This draft defines extensions to the BGP Link-state address-family to carry path segment information via BGP. "Knowledge obtained from the implementation experience of an IODEF- capable incident response management system", daisu-mi@nc.u-tokyo.ac.jp, Takeshi Takahashi, 2014-02-12, This document explains our observation on the usability of IODEF [RFC5070], based on our experiments. We aim at developing an IODEF- capable incident response management systems in order to facilitate incident response activities. We started to design and implement the system for our university CERT, however, there are several technical issues while implementing and operating the system. This document shares the observation from our proto-type implementation and provides new sight from operational aspects. "Metadata Considerations", Bruno Rijsman, Jerome Moisand, 2014-02-12, This draft discusses the topic of metadata in the context of Service Function Chaining. It aims to define the problem space for metadata signaling, identify the key challenges, and guide the exploration and comparison of possible solutions. "Energy-efficient Management Framework", Younghwan Choi, Sangjin Jeong, 2014-04-27, Wireless network devices which have limited resources (e.g., power supply, memory, computing capabilities, and so on) should consider energy-efficient management. However, the existing network architectures for the network devices have some problems on energy management about device failures and errors. To improve the energy management problem, this document proposes energy-efficient management framework for the network devices. "An Information model for service topology", Susan Hares, Wenson Wu, Xiaoran Guan, 2014-02-12, As stated in [I.D-quinn-nsc-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, Florin Balus, Wim Henderickx, Vinay Bannai, Ravi Shekhar, Anil Lohiya, 2014-02-13, 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. "Performance Metrics for Web Browsing", Peng Fan, 2014-02-12, This document specifies metrics to evaluate performance for web browsing service. "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, 2014-02-12, To solve the problem of BGP Identifier in an IPv6-only network without special configuration and planning considerations, this document extends BGP to allow a BGP Identifier to be a valid IPv6 global unicast address assigned to the BGP speaker. Protocol extension includes the definition of a BGP capability code, "IPv6 BGP Identifier capability", to be used by a BGP speaker to indicate its support for IPv6 address as a BGP Identifier. This document updates RFC 4271. "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip Eardley, Al Morton, 2014-02-12, This document specifies the common aspects of the IANA registry for performance metrics, both active and passive categories. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. "Consideration of Routing Optimization for DMM network", Xinpeng Wei, 2014-02-12, Distributed Mobility Management (DMM) is designed to be a distributed and scalable mobility management solution, and providing optimal route for traffics is one of DMM's aims. There have been several proposals on DMM framework, and this document provides discussion on how to optimize traffic routes, and aims to provide suggestioins on how to avoid long route in DMM network. "Using Generic Bootstrapping Architecture with Constrained Devices", Mohit Sethi, Vesa Lehtovirta, Patrik Salmela, 2014-02-13, This document discusses the use of the 3GPP Generic Bootstrapping Architecture (GBA) for authenticating and securing constrained devices. While GBA re-uses the 3GPP credentials, it does not require mobile network access, such as LTE, but requires only IP connectivity. Though building devices that employ GBA is obviously well known, this document specifically focuses on techniques necessary to minimize memory and energy consumption which is essential for constrained device networks. "Data Plane Processing Acceleration Framework", Zehn Cao, Fu Qiao, Deng Lingli, 2014-02-13, It is getting popular to running data applications over general purpose hardware/chipsets, instead of customized and dedicated hardware/chipset. This way further decouples the software functions from the hardware. But moving data processing intensive applications to general purpose hardware is still challenging, although the industry has supplied some proprietary solutions. This document discusses the problems of data plane acceleration and proposes its framework. "Service Function Chaining Use Cases in Broadband", Wei Meng, Cui Wang, Bhumip Khasnabish, 2014-05-13, This document discusses about service function use cases in different scenarios for each part of broadband network. The document provides analysis of different solutions and also describes the suitable scenarios that each solution may be deployed in. "Lightweight 4over6 for LTE Networks", Yong Cui, Qi Sun, 2014-02-13, Operators of Long Term Evolution (LTE) networks have been suffering from IPv4 address shortages and are forced to migrate to IPv6. Many operators prefer to build new LTE networks based on IPv6. However, at present there are still a lot of IPv4-only mobile terminals. A large number of high-quality applications are also in the IPv4-only Internet. There exist needs from IPv4 users to access IPv4 Internet across an IPv6-only LTE network. This document describes a tunneling mechanism that enables the IPv4 users to connect to the IPv4 Internet through an IPv6-only LTE network. Port-restricted public IPv4 addresses are assigned to eNodeBs to remove the NAT functionality on the PGW, which helps to offload the processing burden of PGW. The eNodeB is extended to allocate private IPv4 addresses to UEs, as well as the private- public IPv4 address translation. "Analysis of Active-Active Connection Solutions", Hao Weiguo, Li Yizhou, Susan Hares, Durrani, ZTE Corporation, 2014-05-19, Draft [TRILL-Active-PS] lists basic problems which any active-active solutions should address, these problems include frame duplications, loop, MAC address flip-flop and unsynchronized information among member RBridges. For each problem, there may be multiple ways to deal with it. Some solutions solve all or most of the problems listed, and at the same time introduces extra issues. This draft tries to analyze and compare the different solutions for each of the issues, gives a brief summary on the pros and cons, and/or the applicable scenarios. "Clone IKE SA Extension", Daniel Migault, Valery Smyslov, 2014-03-13, This document considers a VPN End User setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interfaces requires to set an IKEv2 channel on each interface, or on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which may each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily increase load to the VPN client and the authentication infrastructure. This document presents the Clone IKE SA extension, where an additional IKEv2 channel is derived from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. "Global Synchronization Protection for Packet Queues", Wolfram Lautenschlaeger, 2014-02-13, Transmission capacity sharing TCP flows tend to synchronize among each other. This way rate variations of the individual flows, which are caused by the congestion control algorithms, do not even out. 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 rationale and is not heuristic, and it has been tested with a Linux implementation. "ALTO Incremental Updates", Bill Roome, Nico Schwan, 2014-02-13, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information. This allows applications to make informed decisions, for example when selecting a target host from a set of candidates. Therefore an ALTO server provides network and cost maps to its clients. However, those maps can be very large, and portions of those maps may change frequently (the cost map in particular). This draft presents a method to provide incremental updates for these maps. The goal is to reduce the load on the ALTO client and server by transmitting just the updated portions of those maps. "DNSSEC Validators Requirements", Daniel Migault, 2014-02-13, 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. "PCP Tunnel-ID Option", Andreas Ripke, Thomas Dietz, Juergen Quittek, Rafael Silva, 2014-02-13, This document describes a new Port Control Protocol (PCP) option called TUNNEL_ID. It serves for identifying a Third Party in addition to the means that PCP's THIRD_PARTY option already provides for that purpose. "IANA Considerations for CFM (Connectivity Fault Management) Code Points", Donald Eastlake, 2014-05-22, IEEE 802.1 has specified Connectivity Fault Management (CFM) OAM facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV (type, length, value) structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA Considerations for the assignment of values from these blocks. INTERNET-DRAFT IANA Considerations for CFM Code Points "Resource Public Key Infrastructure (RPKI) Resource Transfer Protocol and Transfer Authorization Object (TAO)", Edric Barnes, 2014-02-13, This document defines an extension to the rpki-updown protocol to provide support for transferring Internet Number Resources from one INR holder to another. Such transfers take place external to the RPKI, using procedures defined within and between RIRs. This protocol facilitates automation of the maintenance of RPKI data in the context of INR transfers. The protocol supports asynchronous transfers of live or unused INRs within an RIR or between RIRs. The scope of this protocol is limited to the transfer of Internet Number Resources within the Resource Public Key Infrastructure. In support of this protocol, this document also defines a new signed object type for the RPKI repository system, the Transfer Authorization Object (TAO). "The WS resource record: dispersing trust in the DNSSEC root keys", Tony Finch, 2014-02-13, At the moment the root DNSSEC key is a single point of trust and a single point of failure for the whole system. This memo describes a mechanism for dispersing trust in the root key. Witnesses vouch for the root trust anchor by publishing WS records in the DNS. Validators only update their root trust anchors if multiple witnesses agree. The root-witnesses.arpa zone enables a validator to bootstrap trust when it has no working trust anchors other than its witnesses. "Experience from MAP-T Testing", Edwin Cordeiro, Rodrigo Carnier, Antonio Moreiras, 2014-04-15, 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. "Secure MPTCP", Marcelo Bagnulo, 2014-02-13, This memo contains some initial thoughts about how to secure MPTCP. As currently defined, MPTCP provides basic security features to protect the MPTCP signaling and the data flows unprotected. In this note, we explore the possible use to tcpcrypt to provide enhanced security to MPTCP. "ALTO metrices for expressing availability information", Sebastian Kiesel, Michael Scharf, 2014-02-13, This document specifies new metrices to be used with the ALTO protocol. The goal is to provide information about the availability of physical network, host, and storage infrastructures to management systems that orchestrate virtual infrastructures on top of them. Terminology and Requirements Language This document makes use of the ALTO terminology defined in [RFC5693] and [RFC6708]. "Layer 2 Gateway (L2GW)", Liang Xia, Lucy Yong, 2014-02-13, Layer 2 Gateway (L2GW) is used for interconnecting layer 2 overlay network [NVO3FRWK] with layer 2 bridge networks [IEEE802.1Q] to form one layer 2 virtual network. This draft discusses which Layer 2 Control Protocol (L2CP) specified in IEEE802.1 should be supported by the layer 2 overlay network and which not, and specifies how L2GW should deal with L2CP frames. "An Information Model for I2RS Reading Information Policy", Susan Hares, Wenson Wu, 2014-02-13, The Interface to the routing system (I2RS) specifies a new interface that a client (I2RS client) can utilize to interface to the routing system. Some applications that utilize the services of I2RS client may require a specific set of data in response to network events or conditions based on pre-established rules. In order to reduce the data flow through the network, the I2RS client needs to signal the I2RS agent to filter some of the collected data or events prior to transmission to the i2rs client. This functionality is necessary to meet the requirements I2RS enabled services which include service- layer routing improvements, and control of traffic flows and exit points. This document introduces a read-only I2RS RIB policy Informational Model that provides filters for the reads and notifications from the I2RS RIB Info Model (IM). This model utilizes a generic information model (IM) for policy templates that is extensible and hierarchical. These templates support the features described by the I2RS architectural model. "A Bandwidth Attribute for TURN", Martin Thomson, Bernard Aboba, Alan Johnston, Oleg Moskalenko, 2014-02-13, An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow. The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server. "Use Cases and Requirements of Dynamic Service Control based on Performance Monitoring in ACTN Architecture", Yunbin Xu, Guoying Zhang, Weiqiang Cheng, zhenghaomian@huawei.com, 2014-02-13, 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, Dave Mitchell, Andrew Newton, 2014-02-13, The query/response transactions of the Domain Name System (DNS) can disclose valuable meta-data about the online activities of DNS' users. The DNS Security Extensions (DNSSEC) provide object-level security, but do not attempt to secure the DNS transaction itself. For example, DNSSEC does not protect against information leakage, and only protects DNS data until the last validating recursive resolver. Stub resolvers are vulnerable to adversaries in the network between themselves and their validating resolver ("the last mile"). This document details a new DANE-like DNS Resource Record (RR) type called IPSECA, and explains how to use it to bootstrap DNS transactions through informing entries in IPsec Security Policy Databases (SPDs) and to subsequently verifying Security Associations (SAs) for OE IPsec tunnels. "Survey of WebRTC based P2P Streaming", Rachel Huang, Yunfei Zhang, 2014-02-13, This document presents a survey of current emerging WebRTC based P2P streaming applications available on the nowadays Internet. "End Point Properties for Peer Selection", Deng Lingli, Haibin Song, 2014-06-23, The initial purpose for ALTO protocol is to provide better than random peer selection for p2p networks. The peer selection method does not only depend on the peer location, but also on other properties of a peering node. In this document, we define endpoint property extensions besides peer location that will impact peer selection. "Extensions to Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", Xian Zhang, zhenghaomian@huawei.com, Oscar de Dios, Victor Lopez, 2014-02-13, 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 two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is a centralized entity, responsible for path calculation. 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. "Gap Analysis for Autonomic Networking", Michael Behringer, Brian Carpenter, Sheng Jiang, 2014-02-13, This document summarises a problem statement for an IP-based autonomic network that is mainly based on distributed network devices. The document reviews the history and current status of autonomic aspects of IP networks. It then reviews the current network management style, which is still heavily depending on human administrators. Finally the document describes the general gaps between the ideal autonomic network concept and the current network abilities. "Extensions to ISIS for Source Label Distribution", Mach Chen, Greg Mirsky, 2014-02-13, An MPLS Source Label (SL) is defined to identify a node that is (one of) the ingress LSRs to a specific LSP. This document defines extensions to ISIS protocol for distribution of the mapping of an MPLS Source Label to an specific LSR. Therefore, the egress and intermediate LSRs can determine from which LSR an MPLS packet is sent. This document also defines ISIS extensions to advertise the Source Label Capability (SLC) of each LSR that indicates whether an LSR can process the Source Label. With the SLC, an ingress LSR can determine whether it is allowed to insert a Source Label into the label stack for a specific LSP. "Extensions to OSPF for Source Label Distribution", Mach Chen, Greg Mirsky, 2014-02-13, An MPLS Source Label (SL) is defined to identify a node that is (one of) the ingress LSRs to a specific LSP. This document defines extensions to OSPF protocol for distribution of the mapping of an MPLS Source Label to an specific LSR. Therefore, the egress and intermediate LSRs can determine from which LSR an MPLS packet is sent. This document also defines OSPF extensions to advertise the Source Label Capability (SLC) of each LSR that indicates whether an LSR can process the Source Label. With the SLC, an ingress LSR can determine whether it is allowed to insert a Source Label into the label stack for a specific LSP. "Deterministic URI Encoding", Osama Mazahir, Dave Thaler, Matthew Cox, Gabriel Montenegro, 2014-02-13, The "http" and "https" URI schemes do not have a fixed character encoding. This document defines HTTP headers to enable an explicit indication of the character encoding. "I2RS Traffic Steering Use Case", Mach Chen, Susan Hares, 2014-02-13, I2RS intends to be a standard, programmatic interface to the routing system that guides traffic in the network. A well designed Traffic Steering (TS) solution can fully use the network bandwidth, reduce the network congestion and satisfy the performance (e.g., delay, loss) requirement of applications. Most of the existing TS solutions need human intervention and are lack of dynamic feedback and self- adjust ability. This document describes use cases that leverage the I2RS interface to perform traffic steering dynamically and automatically. "TRILL anycast Layer 3 Gateway", Hao Weiguo, Li Yizhou, Donald Eastlake, Radia Perlman, 2014-02-13, This draft mainly describes centralized anycast layer 3 gateway solution in TRILL campus. Comparing to traditional VRRP based active-standby layer 3 gateway solution, this solution can achieve better load balancing and scalability. Anycast nickname, anycast gateway IP and MAC are introduced. It can ensure inter-subnet traffic forwarding in flow-based load balancing mode among all physical layer 3 gateways. To avoid sending duplicated ARP reply message to the end system, ARP master gateway election mechanism is introduced. The election algorithm is described in this draft. "Network as a Service Architecture", Vic Liu, Liang Xia, 2014-02-13, This draft provides an high-level overview architecture of Network as a Service (NaaS) system, and describes how every component of it works together from different aspects (i.e., data plane, control plane, management plane, etc) of NaaS system. "Requirements for a Network Disaster Recovery System", Toshiaki Suzuki, 2014-02-13, Requirements concerning a network disaster recovery system such as a wide area network management system based on Software Defined Networking (SDN) architecture are presented. Specifically, a multi- layer network management system, which is composed of multiple network layers, layer management functions to manage each network layer, and integrated-layer management, is focused on. The problems that need to be overcome in order to consistently manage dmake the system are presented. The requirements that should be satisfied in order to solve these problems are presented. "DHCPv4 over DHCPv6 Source Address Option", Ian Farrer, Qi Sun, Yong Cui, 2014-02-13, DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes one possible mechanism for dynamically configuring IPv4 over an IPv6 only network. For DHCPv4 over DHCPv6 to function with some softwire mechanisms, the operator must obtain information about the DHCP 4o6 client's allocated IPv4 address and PSID, as well as the /128 IPv6 prefix that the client will use as the source of IPv4-in-IPv6 tunnel. This memo defines a DHCPv6 option to convey this IPv6 prefix between the DHCP 4o6 client and server. It is designed to work in conjunction with the DHCPv4 IPv4 address allocation process message flow. "Service Function Controller/Orchestration Requirements and Templates", Zehn Cao, Hui Deng, 2014-02-13, Service Function Chain architecture further enables the modularity of network functions; network service functions can be split and chained together to compose complicated services. Network automation relies on a specific orchestrator to automatically deploy an end2end service or application. If this end2end service or application has a specific requirement to chaining several service functions, there is a need of an interface from the application to inform the orchestrator. This document investigates the problem. "The Benefits to Applications of using Explicit Congestion Notification (ECN)", Michael Welzl, Gorry Fairhurst, 2014-02-13, 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. "Resource Pooling Mechanism for Multi-Layer Operations", Tomoyuki Iijima, 2014-02-13, This memo proposes resource pooling mechanism for multi-layer operations. Resource pool is often discussed in the context of robustness and restoration. But, resource pooling mechanism should also be used for realizing flexibility in multi-layer network operations. Today, it takes days or weeks of lead time to change wide area networks composed of multiple network layers. One of the reasons is because communications between operators of different network layers are necessary before configuration of each layer is made. A network management system that uses resource pooling mechanism would get rid of communications made between operators of different network layers, and would realize flexible changes in multi-layer networks. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Signaling Procedure for Resource Sharing-based LSP Setup/Teardown", Xian Zhang, zhenghaomian@huawei.com, 2014-02-13, Generalized Multiprotocol Label Switching (GMPLS) defines a set of protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. It can be used for different types of switching technologies. This document compliments existing standards by explaining the missing pieces of information during the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) signaling procedure in support of resource sharing-based LSP setup/teardown in GMPLS-controlled circuit networks. "TURN Extension for Third Party Authorization", Tirumaleswar Reddy, Prashanth Patil, Ram R, Justin Uberti, 2014-06-19, This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for TURN authentication. The usage of ephemeral tokens ensure that access to a TURN server can be controlled even if the tokens are compromised, as is the case in WebRTC where TURN credentials must be specified in Javascript. "TRILL Active-Active Edge Using Multiple MAC Attachments", Mingui Zhang, Radia Perlman, ZTE Corporation, Durrani, Mukhtiar Shaikh, Sujay Gupta, 2014-06-16, TRILL active-active service provides end stations with flow level load balance and resilience against link failures at the edge of TRILL campuses. This draft specifies a method in 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. "Considerations regarding the correct use of EAP-Response/Identity", Stefan Winter, 2014-02-14, There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. "Service Function Chain Control Plane Overview", Qin Wu, Wang Danhua, Mohamed Boucadair, Christian Jacquenet, XianGuo Zhang, Yang Shi, 2014-02-14, As described in [I.D-boucadair-sfc-framework], the dynamic enforcement of a Service-derived, adequate forwarding policy for packets entering a network that supports such advanced Service Functions has become a key challenge for operators and service providers. This document is based on [I.D-boucadair-sfc-framework] and focusing on discussing how the Service Functions are discovered and provisioned and how Service Function Chaining path is setup. "WebSocket over HTTP/2.0", Yutaka Hirano, 2014-02-14, The WebSocket protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. Since it requires one TCP connection for every WebSocket connection, having multiple WebSocket connections between the same client and the same server is inefficient. On the other hand, HTTP/2.0 specifies a fast, secure, multiplexed framing protocol. This document provides bi- directional multiplexed communication by layering WebSocket on top of HTTP/2.0. Please send feedback to the ietf-http-wg@w3.org mailing list. "FIB Reduction in Virtual Subnet", Xiaohu Xu, Susan Hares, Fan Yongbing, Christian Jacquenet, Truman Boyes, Brendan Fee, 2014-02-14, Virtual Subnet is a L3VPN-based subnet extension solution which can be used to build 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. "DHCPv6/SLAAC Interaction Implementation Guidance", Bing Liu, Ron Bonica, 2014-02-14, ND and DHCPv6 protocols could have some interaction on address provisioning with the A, M, and O flags defined in ND protocol. But the relevant standard definitions of the flags contain ambiguity, so that current implementations in operating systems have varied on interpreting the flags. The variation might impact real network operations, so this document aims to provide some guidance on what should be the proper implementation on the interaction behavior. "IPv6 Multicast Address With Embedded IPv4 Multicast Address", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 2014-02-14, This document reserves one bit (M-bit) of the unicast prefix-based multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM mode to be used in the context of IPv4-IPv6 interconnection. The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes. "Requirements and Use Cases for Virtual Network Functions", Liang Xia, Qin Wu, Daniel King, Hidetoshi Yokota, Naseem Khan, 2014-05-15, Network function appliances such as subscriber termination, firewalls, tunnel switching, intrusion detection, and routing are currently provided using dedicated network function hardware. As network function is migrated from dedicated hardware platforms into a virtualized environment, a set of use cases with application specific resilience requirements begin to emerge. These use cases and requirements cover a broad range of capabilities and objectives, which will require detailed investigation and documentation in order to identify relevant architecture, protocol and procedure solutions to ensure reliance of user services using virtualized functions. This document provides an analysis of the key reliability requirements for applications and functions that may be hosted within a virtualized environment. These NFV engineering requirements are based on a variety of uses cases and goals , which include reliability scalability, performance, operation and automation. Note that this document is not intended to provide or recommend protocol solutions. "Diameter Overload Rate Control", Steve Donovan, Eric Noel, 2014-02-14, This specification documents an extension to the Diameter Overload Control (DOC) base solution. This extension adds a new overload control algorithm. This algorithm allows for a server to specify a maximum rate at which Diameter requests are sent to the server. Requirements "6TiSCH Operation Sublayer (6top)", Qin Wang, Xavier Vilajosana, Thomas Watteyne, 2014-02-14, The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A cell in that schedule corresponds to an atomic link- layer resource, and can be allocated to any pair of neighbors in the network. This allows the schedule to be built to tightly match each node's bandwidth, latency and energy constraints. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of scope of the standard. This document describes the 6TiSCH Operation Sublayer (6top) and the commands it provides to upper network layers such as RPL or GMPLS. The set of functionalities includes feedback metrics from cell states so network layers can take routing decisions, TSCH configuration and control procedures, and the support for decentralized and centralized scheduling. In addition, 6top can be configured to enable packet switching at layer 2.5, analogous to GMPLS. "Additional WebRTC audio codecs for interoperability with legacy networks.", Stephane Proust, Espen Berger, Bernhard Feiten, BoB, Kalyani Bogineni, Miao Lei, Enrico Marocco, 2014-02-14, 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. "Service Function Chaining Verification", Seungik Lee, Myung-Ki Shin, 2014-02-14, This document addresses the possible conflicts among different service function chains. These conflicts may occur when 1) a traffic flow satisfies two or more classification rules of different service function chains; and 2) a service function cannot provide enough resource for a service function chain due to load of other service function chains. These conflicts need to be detected and resolved at deploying a new service chain. "Deep Performance Visualization: Use Cases, Requirements and Framework", Peng Fan, Zhen Cao, 2014-02-14, Providing deep performance information by the networks is expected in many use cases. This document intends to discuss a unified presentation of performance, by investigating use cases that benefit from performance information, describing relevant requirements, and proposing a framework of how the components work together to enable deep performance visualization. "Validation of Neighbor Discovery Source Link-Layer Address (SLLA) and Target Link-layer Address (TLLA) options", Fernando Gont, Ron Bonica, Will, 2014-02-14, This memo documents two scenarios in which an on-link attacker emits a crafted IPv6 Neighbor Discovery (ND) packet that poisons its victim's neighbor cache. In the first scenario, the attacker causes a victim to map a local IPv6 address to a local router's own link- layer address. In the second scenario, the attacker causes the victim to map a unicast IP address to a link layer broadcast address. In both scenarios, the attacker can exploit the poisoned neighbor cache to perform a subsequent forwording-loop attack, thus potentially causing a Denial of Service. Finally, this memo specifies simple validations that the recipient of an ND message can execute in order to protect itself against the above-mentioned threats. "X.509 Public Key Infrastructure Certificates for the Constrained Application Protocol (CoAP)", Pawani Porambage, Corinna Schmitt, Andrei Gurtov, Stefanie Gerdes, 2014-02-14, The Constrained Application Protocol (CoAP) is a web transfer protocol designed for resource limited nodes in constrained networks. For securing the protocol, CoAP defines a binding to Datagram Transport Layer Security (DTLS) with four security modes. One of them is the Certificate mode where the device has an asymmetric key pair with an X.509 certificate. However, the intrinsic properties of x.509 certificates impede the application on the resource constrained nodes. This draft describes the necessary adjustments and derives a modified profile for X.509 certificates to cope with the resource limitations of low-power low-performing devices "Problem Statements of Virtualizing Home Services", Yiu Lee, Rajat Ghai, 2014-02-14, Network Virtualization is proven a success to more effectively manage services in data center. This draft states the motivations and problem statements of decoupling services from Customer Premises Equipment (CPE) and virtualizing them in the Network Service Provider (NSP). "Evaluation Test Cases for Interactive Real-Time Media over Cellular Networks", Zaheduzzaman Sarker, Ingemar Johansson, 2014-02-14, 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 a cellular network such as LTE network. It is aimed that the proposed solutions should be evaluated using the test cases defines in this document to select most optimal solutions. "ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy for Transport Layer Security (TLS)", Lars Schmertmann, Carsten Bormann, 2014-02-14, RFC 6655 describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. It has been chosen as one of the preferred cipher suites for use with DTLS in the Constrained Application Protocol, CoAP. The present document defines additional cipher suites that provide forward secrecy. It also discusses an option to replace the Hash- based PRF in RFC 6655 by CMAC, reducing the number of cryptographic primitives required for implementation. (The intention is that the option is either chosen or not chosen before this document is agreed, not that both options are defined.) This document is initially addressed at the DICE working group in order to build consensus that there is an actual gap to be filled and about the technical parameters of a solution for that gap. Once this is agreed, the usual path for agreeing a cipher suite will need to be taken. "Virtualizing Home Services Use Cases", Yiu Lee, Chongfeng Xie, 2014-02-14, This draft states some high-level use cases of virtualizing home services. "Unified IPv6 Transition Framework With Flow-based Forwarding", Yong Cui, Yuchi Chen, 2014-03-04, This document describes a unified IPv6 transition framework. This framework makes use of the flow-based packet forwarding technology, which can simplify the implementation of both control plane and data plane operations of transition mechanisms. The purpose of this work is to provide an integrated and flexible framework to implement and deploy the most popular translation and tunneling mechanisms, such as NAT64, DS-Lite, Lightweight 4over6 and MAP-E. This framework can benefit the industry by reducing the cost of implementation, providing flexibility for deployment, and enabling transition mechanisms to coexist and cooperate in the common infrastructure. "Authentication and Authorization for Constrained Environments (ACE): Overview of Existing Security Protocols", Hannes Tschofenig, 2014-02-14, This document surveys existing three party authentication and authorization protocols for use with Internet of Things use cases. The discussed protocol frameworks are Kerberos, OAuth, ABFAB, and the certificate model. The aim is to understand whether any of the available standardized security protocols are re-usable for constrained environments. A future version of this document will provide a more detailed analysis against the requirements. "NaaS (Network as a service) requirement", Vic Liu, Chen Li, 2014-02-14, Naas one of the use case based on Network Virtualization Overlay (NVO3).This draft describes some specific requirement of NaaS in cloud datacenter. "Considerations on Transport Services API for Data Centers", Deng Lingli, 2014-03-02, It is noticed that within a data center, unique traffic pattern and performance goals for the transport layer exist, as compared to things on the Internet. This draft discusses the usecases for applying transport APIs from the perspective of an application running in a data center environment, and proposes potential requirements for such API design. "MPTCP Proxy for Mobile Networks", Deng Lingli, Dapeng Liu, Tao Sun, 2014-02-14, This document discusses the motivation and usecases for ISP deployed MPTCP proxies in mobile networks. "The Shadow Internet: liberation from Surveillance, Censorship and Servers", Johan Pouwelse, 2014-02-14, This document describes some scenarios and requirements for Internet hardening by creating what we term a shadow Internet, defined as an infrastructure in which the ability of governments to conduct indiscriminate eavesdropping or censor media dissemination is reduced. "Utilizing traffic offloading to relieve burden of service node", Hao Chen, Jishang Yang, 2014-02-14, This document analysis the possibility to relieve the burden of service node via introducing the traffic offloading mechanism into the service function chain scenario, which may ultimately improve the network efficiency. "Path Computation Element to Support Software-Defined Transport Networks Control", zhenghaomian@huawei.com, Xian Zhang, 2014-02-14, This draft describes PCE architecture and protocol in SDN-based transport network. It is demonstrated that PCE can fit in the transport SDN architecture and complete corresponding requests. The PCE and its protocol can satisfy the functional requirement in several transport SDN applications. "Radius Extension for Lightweight 4over6", Jianping Wu, Qi Sun, ZiLong Liu, 2014-02-14, IPv4-over-IPv6 tunneling transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6(DHCPv6) options has been extended and defined to configure tunnel initiator (TI) in lightweight 4over6. However, in many networks, the configuration information are stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. Thus AAA server as a database can be extended to establish and store the whole information of tunnels and help the tunnel concentrator (TC) recover in failure. This document defines the mechanism and the Remote Authentication Dial In User Service (RADIUS) attributes that carry TI configuration information from AAA server to BNG and the tunnel configuration information from AAA server to TC. "Communication between Softwire CEs with shared addresses", Jianping Wu, Cong Liu, 2014-02-14, In some Softwire mechanisms, multiple Customer Edge (CE) devices can share the same IPv4 address by using different port sets. This document describes a problem of the IPv4 communication between Softwire CEs with the same IPv4 address. "Transport Layer Security (TLS) Client authentication Using IEEE 1609-2 Certificate", Mohamad Badra, Houda Labiod, Brigitte Lonc, F. Lonc, Ahmed Serhrouchni, 2014-02-14, This document describes two types of certificates to authenticate TLS entities, the first type enables the use of a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) and the second by the European Telecommunications Standards Institute (ETSI). This document defines a new extension to enable TLS entities authentication using one of the aforementioned certificate types. "End Host Mobility Use Cases for LISP", Yves Hertoghs, Marc Binderberger, 2014-02-14, This memo proposes use cases for LISP in the area of end Host mobility. The applicability of end host mobility can be found in data centers, where Virtual Machines (VM's) can be moved freely from one physical server onto another physical server, independent of location, without having to change the IP/MAC-addresses inside those VMs, nor impacting traffic flows to and from those VMs. Wireless end hosts are another area of applicability. Although this draft will not address wireless end host mobility, most of the same principles apply. Traditionally L2 extension technologies have been used to handle mobility events, but they could lead to suboptimal routing of traffic to and from the end host after the mobility event, as well as created big broadcast domains. This memo describes how LISP solves the traffic optimization issues caused by a mobility event of an end host like a Virtual Machine, as it decouples the identity of the end host from its location, such that traffic will always be forwarded to the correct location. More-over the LISP control plane can be leveraged to discover and distribute the reachability information of end hosts such that end to end broadcast domains, and their associated problems, are no longer needed. Various sub-use cases will be looked at in this draft, depending on whether mobility is achieved at L2 (using MAC-addresses as EID) or at L3 (using IP addresses as EIDs), and whether subnets are L2 extended across LISP sites or not. This memo also describes how to handle mobility in the case where the default gateway of the end host is not capable of performing the LISP map-and-encap function, while the LISP xTR function is located one or more L3 hops away from the default gateway. "An Optimization for the MANET Neighborhood Discovery Protocol (NHDP)", Christopher Dearlove, Thomas Clausen, 2014-06-20, The link quality mechanism of the MANET Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold, while still retaining the corresponding link information as acquired from HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" as described above, then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. This specification updates NHDP, and the Optimized Link State Routing Protocol version 2 (OLSRv2) to permit retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust". "Information model for Policy Based Routing", Sriganesh Kini, Ron Folkes, Jan Medved, ramki, Anoop Ghanwani, 2014-02-14, Policy Based Routing (PBR) is a generic term that describes functionality that currently exists in several routing systems where packets are routed, not just based on the destination address but rather based on a policy that is configured/programmed in the router. This document describes the information model for PBR as it exists in many current implementations. "DHCP Options for Configuring VXLAN Network Identifier and Multicast Addresses in VXLAN", Behcet Sarikaya, Frank Xia, Fan Shi, 2014-05-14, This document defines DHCPv4 and DHCPv6 options for assigning VXLAN Network Identifier and multicast addresses for the Tunnel End Point in the Virtual eXtensible Local Area Network (VXLAN) environments. New DHCP options are defined which allow a VXLAN Tunnel End Point or Network Virtualization Edge to request any source multicast address for the newly created virtual machine. "LISP Deployment Considerations in Data Center Networks", Victor Moreno, Fabio Maino, Darrel Lewis, Michael Smith, Satyam Sinha, 2014-02-14, This document discusses scenarios and implications of LISP based overlay deployment in the Data Center. The alternatives for topological location of the different LISP functions are analyzed in the context of the most prevalent Data Center topologies. The role and deployment of LISP in the Wide Area Network and Data Center Interconnection are also discussed. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 2014-02-14, [This version of the document is a draft version for an RFC6044bis that will describe the mapping between the Diversion header defined in RFC5806 and the new History-Info header defined in RFC7044.] Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless already implemented and used for conveying call diversion related information in the Session Initiation Protocol (SIP) signaling. This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The non-standard Diversion header is described, as Historic, in [RFC5806]. The History-Info header is described in [RFC7044] that obsoletes [RFC4244] initially describing the History-Info header. [RFC7044] defines an optional SIP header field, History-Info, for capturing the history information in requests and 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 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 work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document obsoletes [RFC6044]. "Cloud Based Mobile Core Network Problem Statement", Dapeng Liu, Anthony Chan, Hui Deng, 2014-03-03, 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. "Providing support for multiple namespaces to Internet protocols.", Olafur Gudmundsson, 2014-02-14, Over the years there have been various proposals as to use namespaces other than the DNS/IN namespace that is under ICANN administration. Some of these were simple DNS competitors others use different lookup technologies. In addition it is hard to supply different character encodings to DNS as each application needs to provide the translation between the encoding used and the format expected by DNS. This draft proposes a new service layer to provide multiplexing of different namespaces into appropriate function calls. "LISP Data-Plane Confidentiality", Dino Farinacci, 2014-02-14, 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. "Design Considerations for Security Protocols in Constrained Environments", Ludwig Seitz, Goran Selander, 2014-02-14, Considerable effort has been spent on securing existing Internet standard authentication and authorization protocols such as TLS, Kerberos, and OAuth, among others. It would save a lot of effort if these protocols could be profiled to be feasible for constrained environments, with some easily obtainable security considerations. However, these protocols were typically not designed with constrained environments in mind, so profiling of an existing protocol may result in a far from optimal solution. Moreover they are not necessarily complying with their original design objectives outside their intended domain of application. This document examines the impact of typical characteristics of security protocols (e.g. cryptographic calculations, number and size of protocol messages) in a constrained environment. The goal is to provide decision support when different resource usage optimizations are possible in the adaptation of a security protocol for this setting. "Secure Telephone Identity Credentials: Certificates", Jon Peterson, Sean Turner, 2014-02-14, In order to provide a means of proving ownership of telephone numbers on the Internet, some kind of public structure 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. "Overview for MSRP Recording based on SIPREC", Michael Yan, Paul Kyzivat, 2014-05-28, 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). "Central Directory Approach for Mapping VTEP IP Address to VM MAC/IP address in VXLAN", Behcet Sarikaya, Frank Xia, 2014-02-14, This document proposes a central database for the address resolution and neighbor discovery protocols in Virtual eXtensible Local Area Network or VXLAN environments. An entry is added to the database when a virtual machine is created and an IP address is assigned. When a hosted Virtual Machine makes an ARP/ND Request, the source Virtual VXLAN tunnel end point, after searching the central database, sends Virtual Machine's address resolution and neighbor discovery replies in unicast to the hosted Virtual machine. The document also defines DHCPv4/v6 options for DHCPv4/v6 ARP/ND Directory Server IP Address and VXLAN Network Identifier. "Use Cases for Abstraction and Control of Transport Networks (ACTN)", Dhruv Dhody, Xian Zhang, Oscar de Dios, 2014-02-14, This document describes the Abstraction and Control of Transport Networks (ACTN) use cases that may be potentially deployed in various transport networks and apply to different applications. "Virtualisation of Mobile Core Network Use Case", Daniel King, Marco Liebsch, Peter Willis, Jeong-dong Ryoo, 2014-06-08, 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). "CoDTLS: DTLS handshakes over CoAP", Lars Schmertmann, Klaus Hartke, Carsten Bormann, 2014-02-14, The Datagram Transport Layer Security protocol, DTLS, is usually transported over UDP. In Constrained Node Networks, there may be considerable limitations on the packet delivery rates and on practically usable packet sizes. Applications often can control the size and retransmission requirements of their data packets, but the DTLS handshake is out of scope for such application optimizations. This specification defines how to perform a DTLS handshake on top of the CoAP protocol. The resulting DTLS connection may then be used for instance for transporting CoAP, or as a source of keying material. The latter case is particularly interesting if the CoAP exchanges transporting the DTLS handshake messages traverse CoAP proxies. "VLAN Service Function Chaining", David Dolson, 2014-02-14, This document describes an implementation of Service Function Chains (SFC) utilizing standard VLAN switching, appropriate for bump-in-the- wire Service Function nodes. "NetInf Protocol Extensions for Cache Control", Bengt Ahlgren, Borje Ohlman, 2014-02-14, This document defines NetInf protocol extensions for controlling caching behaviour. This includes bypassing caches, asking to not return data, setting expiration time for objects, and marking objects as non-cacheable. "Implementing RPKI-based origin validation one country at a time. The Ecuadorian case study.", Fabian Mejia, Roque Gagliano, Alvaro Retana, Carlos Martinez, Gerardo Rada, 2014-02-14, 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. "Starting TLS over DNS", Zi, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, 2014-02-14, This document describes a technique for upgrading a DNS TCP connection to use Transport Layer Security (TLS) over standard ports. Encryption provided by DNS-over-TLS eliminates opportunities for eavesdropping of DNS queries in the network. The proposed mechanism is backwards compatible with clients and servers that are not aware of DNS-over-TLS. "Signaling AFI-SAFI scope for Constrained Route Distribution", Saikat Ray, Arjun Sreekantiah, 2014-02-14, The Route Constrain address family can be used by a BGP speaker to signal a neighbor its interest in receiving only the routes with a matching route target (RT) extended community. This signaling is afi-safi agnostic; the sender of a route constrain NLRI with an RT expresses its interest in receiving routes with that RT for all afi- safi. The ability to further scope a given RT to a list of afi-safi would simplify network operations; then optimal route filtering would no longer require that the set of RTs used for different afi-safi be disjoint. This document proposes a simple extended community based backward compatible method to associate the list of afi-safi of interest to a route constrain NLRI and discusses the operational procedure. "OAM Requirements for Segment Routing Network", Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Ruediger Geib, Greg Mirsky, 2014-02-14, This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. "Ephemeral keying for ABFAB", Linus Nordberg, Josh Howlett, 2014-03-06, This document describes how EAP-GSS provides forward secrecy by encrypting each session in an ephemeral key generated in the initial state of the context establishment. This Diffie-Hellman key is shared by the initiator (EAP peer) and acceptor (EAP authenticator). The goal is to stop a passive attacker with access to the traffic between an ABFAB user and the service she uses (Relying Party), from getting access to key material and information linkable to the user or from being able to fingerprint the user. "Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan, 2014-02-14, This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IP host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is among the key goals of "MPLS Fabric" architecture. "Opportunistic Encryption", John Mattsson, 2014-02-14, Following the recent pervasive monitoring revelations, one of the discussed remedies has been opportunistic encryption. In this paper, we give an overview of various opportunistic and unauthenticated encryption techniques, discuss their benefits, limits, and disadvantages, and try to conclude how effective they are as a mean to thwart pervasive monitoring. "Test Cases for Evaluating RMCAT Proposals", Zaheduzzaman Sarker, Varun Singh, Xiaoqing Zhu, Michael Ramalho, 2014-06-17, 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. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 2014-02-14, 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. "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", Al Morton, 2014-02-14, BMWG 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. "On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks", Yunjung Yi, Sung-Ju Lee, William Su, Mario Gerla, Axel Verdiere, 2014-03-05, 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. 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. "SDP-based "SCTP over DTLS" data channel negotiation", Keith Drage, Richard Ejzak, Jerome Marcon, 2014-02-14, The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication 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 in-band WebRTC Data Channel protocol or some external (in-band or out-of-band) negotiation. 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 whereever data channels are used. "Exising Practices for Smooth Key Rollover with Interior Routing Protocols", R. Atkinson, 2014-02-14, This document describes some existing deployed operational practices that are in use to provide smooth key rollover for IETF interior routing protocols (e.g. IS-IS, OSPFv2, RIPv2). This is intended for eventual publication as an Informational RFC on the Independent Submission track, not via the IETF track. "Scalable Domain-based Routing Scheme", Joo-Chul Lee, 2014-02-14, This memo describes a scalable routing scheme for information centric networks. Moving the focus from "nodes" to "information objects" raises scalability issue because aggregation of flat name for objects is not easy task and the number of addressable information objects is so huge than the IP address space. For scalable routing, we propose hierarchically-organized domain architecture. A domain is a "logical group" of information objects and each domain has its own ID. The concatenation of domain IDs from top level domain to the current domain plays the role of "locator". Thus, we can get scalable routing table and it is more scalable by means of "topology reduction". More challenging issue is name-based forwarding. It is hard to aggregate forwarding table due to flat name space, therefore we propose "reactive path setup". "Best Common Practise for using OPENPGPKEY records", Paul Wouters, 2014-02-14, The OPENPGPKEY DNS Resource Record can be used to match an email address to an OpenPGP key. This document specifies a Best Common Practise ("BCP") for email clients, MUA's and MTA's for using the OPENPGPKEY DNS Resource Record. "LISP Reliable Transport", Christian Cassar, Isidor Kouvelas, Darrel Lewis, 2014-02-14, 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. "Transport Services and low latency", Andreas Petlund, 2014-02-14, This document categorises different classes of network latency, discusses possible metrics for determining the characteristics of latency-sensitive flows and addresses the use of transport services as a means for achieving transport latency reduction. "ODMRP-ASYM", Mario Gerla, Soon Oh, Axel Verdiere, 2014-02-14, This document describes ODMRP-ASYM, an extension for the On Demand Multicast Routing Protocol (ODMRP) aimed at taking advantage of unidirectional links rather than avoiding them. "Terminology and Models for Control of Traffic Engineered Networks with Provider-Customer Relationship", Oscar de Dios, Julien Meuric, Daniele Ceccarelli, 2014-02-14, Different kinds of relationships can be established among interconnected Traffic Engineered Networks. In particular, this document focuses on the case where there is a customer-provider relation between the network domains. The domain interconnection is a policy and administrative boundary. This informational document collects current terminology and provides a taxonomy for the posible control plane based operation models. Each control model defines, on the one hand, the level of information that the domain acting as customer receives by control plane means from the domain acting as provider and, on the other hand, the control model will determine what can be requested from the customer domain to the provider domain. "IPv6 Periodic RA Cellular Impact Investigation", Fredrik Garneij, 2014-02-14, The use of IPv6 in 3GPP cellular broadband for accessing the Internet and other data services like VoLTE via smartphones has increased as a result of EPS network deployments worldwide and new IPv6 capable smartphones tablets, and netbook computers. The upcoming rise of IoT/M2M is anticipated to bring billions of new devices into these networks and the majority of these devices will be using only IPv6. This document discusses the EPS network impact of IoT/M2M IPv6 connectivity specifically targeting the IPv6 Stateless Address Auto Configuration (SLAAC), as specified in [RFC4861] and [RFC4862], which currently is the only supported IPv6 address configuration mechanism in 3GPP standards. "Reducing Multicast in IPv6 Neighbor Discovery", Andrew Yourtchenko, Lorenzo Colitti, 2014-02-14, IPv6 Neighbor Discovery protocol makes wide use of multicast traffic, which makes it not energy efficient for the mobile WiFi hosts. This document describes two classes of possible ways to reduce the multicast traffic within IPv6 ND. First, within the boundaries of existing protocols. Second - with what the authors deem to be "minor changes" to the existing protocols. "Concise Binary Object Representation (CBOR) Tags for Typed Arrays", Johnathan Roatch, Carsten Bormann, 2014-02-14, 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, 2014-04-18, 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 accepted language of the Series, the encoding of future RFCs will be in UTF-8. This document describes the RFC Editor requirements and guidance regarding the use of non-ASCII characters in RFCs. This document updates [draft-iab-styleguide]. Please review the PDF version of this draft. "LISP Virtual Private Networks (VPNs)", Darrel Lewis, Gregg Schudel, 2014-02-14, This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These IP based VPNs can be created over the top of the Internet or other VPN protocols, and can be implemented by Enterprise or Service Provider type networks. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. "Identification of provisioning domains", Suresh Krishnan, Jouni Korhonen, Shwetha Bhandari, Sri Gundavelli, 2014-02-14, 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. "Geneve: Generic Network Virtualization Encapsulation", Jesse Gross, T. Sridhar, Pankaj Garg, Chris Wright, Ilango Ganga, 2014-02-14, 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 keep pace with the evolution of the system. This draft describes Geneve, a protocol designed to recognize and accommodate these changing capabilities and needs. "DTS Namespace Identifier", Phillip Maness, 2014-02-14, This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources to be used for DTS audio related metadata and signaling parameters. Comments Requested Comments are solicited and should be addressed to phillip.maness@dts.com. "A PIE-Based AQM for DOCSIS Cable Modems", Greg White, Rong Pan, 2014-02-14, 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 are being amended to contain similar requirements. "IETF Policy on Character Sets and Languages", Andrew Sullivan, Dave Thaler, John Klensin, 2014-02-14, This is a proposed new policy for the IETF on Character Sets and Languages. "By Any Other Name: Considerations on DNS, Other Naming Protocols, and the Hierarchical Domain Name Space", Andrew Sullivan, 2014-02-14, You should probably not read this. It's not done. Not every domain name is intended to appear in the global DNS. It is also possible that not everything that looks like a domain name is intended to be one. Regardless of whether a given name is intended to appear in the DNS, such names often turn up in domain name slots. When choosing a naming scheme that is not intended to be part of the global DNS, it is necessary to understand the architectural implications of using domain names or a domain-name-like syntax. "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Quintin Zhao, Katherine Zhao, Dhruv Dhody, Boris Zhang, 2014-02-14, 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.draft-zhao-pce-central-controller-user-cases], we propose to use the PCE as a central controller 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. "DHCPv4 to SLAAC DNS naming", Dave Taht, Evan Hunt, Simon Kelley, 2014-02-14, This memo presents a technique for using the hostname acquired from a DHCPv4 client request to publish AAAA records on that domain name for public IPv6 addresses acquired by the same dual-stack host using SLAAC. On dual-stack networks, there is a need to automatically publish entries in the DNS for the public IPv6 addresses of an IPv6 host when it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using SLAAC, but there is no mechanism allowing them to register a name in the DNS database other than a DNS update, which would create a very difficult key management problem. By combining the DHCPv4 hostname or client FQDN option with information acquired using ICMPv6, a lightweight DHCPv4 server on a home gateway or SOHO gateway can automatically publish AAAA records for such hosts. "A YANG Data Model for Network Topologies", Alex Clemm, Hariharan Ananthakrishnan, Jan Medved, Tony Tkacik, Robert Varga, Nitin Bahadur, 2014-02-14, This document defines a YANG data model for network topologies. "Short Authentication Strings for TLS", Ian Miers, Matthew Green, Eric Rescorla, 2014-02-14, TLS and DTLS connections generally rely on a PKI, a shared secret, or endpoint fingerprints for endpoint authentication. This document describes an authentication mechanism which instead generates a "short authentication string" (SAS) as an emergent property of the connection. The SAS can then be verified via an external channel in order to authenticate the connection. "BGP Link-State Information Distribution Implementation Report", Hannes Gredler, Balaji Rajagopalan, Saikat Ray, Manish Bhardwaj, 2014-02-14, This document is an implementation report for the BGP Link-State Information Distribution protocol as defined in [I-D.ietf-idr-ls-distribution]. 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. "Constrained Certificates for the Constrained Application Protocol (CoAP)", Hauke Mehrtens, 2014-02-14, The present document defines a new kind of certificate suited for constrained environments. This new kind of certificate is intended to be used in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) in combination with Constrained Application Protocol (CoAP). "Requirements for IPv6 Enterprise Firewalls", Fernando Gont, Marco Ermini, Will, 2014-04-15, 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. "Security Authentication of WebRTC Communication Service for Telephony Terminal", Minpeng Qi, Judy Zhu, Ziyao Cheng, 2014-02-18, The WebRTC use-cases and related requirements are defined in [draft-ietf-rtcweb-use-cases-and-requirements] that contains browser to browser use-cases and browser-GW/server use-cases (e.g., telephony terminal). In the use-case of telephony terminal, it is necessary for telephony terminal to be able to attest his identity to the telephony operator. Unlike the current authentication specified in [draft-ietf-rtcweb-security] such as PKI based authentication and web based peer authentication WebRTC communication is directly controlled by the telephony operator, which poses new authentication methods, including re-using existence authentication mechanism of telephony operator and authentication by using web credentials. This document presents the security authentication of WebRTC communication for telephony terminal. "Telecommunication Requirement", Xiaojun Zhuang, Minpeng Qi, Judy Zhu, 2014-03-21, This memo documents describes an additional use case based on telecommunication scenario which is also fit for common enterprise scenario "Group Authentication", Judy Zhu, Minpeng Qi, 2014-02-19, The group communication is designed for the communication of Internet of Things. A threat is identified in [I-D.ietf-core-groupcomm] that current DTLS based approach is unicast oriented and there is no supporting on group authentication feature. Unicast oriented authentication will causing serious burden when a large number of terminal nodes will be involved inevitably. In another aspect, some terminals will own the same characteristics, such as owning same features, in the same place, working in the same time, etc. With this mechanism, all terminals can be authenticated together with little signaling and calculation at the same time. It will reduce the network burden and save time. This draft describes the security of group authentication and an group authentication implementation method for the Internet of things. "A new route discovery scheme", Alok Kumar, Jean-Charles Delvenne, 2014-02-20, This document describes a route discovery scheme in the Internet. It could be well suited for any centralized distributed network like software-defined networks. This scheme could be an alternative of path computation element in inter-Autonomous domains routing protocol. "Using LISP for Secure Hybrid Cloud Extension", Santiago Freitas, Patrice Bellagamba, Yves Hertoghs, 2014-02-21, The purpose of this draft is to document how the Locator/Identifier Separation Protocol (LISP) can be used to enable a secure layer 3-based Hybrid Cloud, which is a composition of two or more distinct cloud infrastructures that remain unique entities, but are bound together to enable data and application portability. It describes how LISP, in combination with IPsec, can be implemented on a virtualized router that is deployed on a public cloud and on the enterprise Data Center to enable cloud bursting, workload migration, rapid provision of new applications in the cloud and disaster recovery use cases. This draft covers how LISP allows virtual machines (VMs) to be moved to the cloud without requiring changes to the VMs IP and/or MAC-address. "RTP Application Interaction with Congestion Control", Mo Zanaty, Varun Singh, Suhas Nandakumar, 2014-03-02, 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 interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface and the congestion control layer. "Authentication-Results Registration for TLS", Franck Martin, 2014-06-17, This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of an email sent using STARTTLS [RFC3207] or not. "Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2014-06-13, 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. "Diet-ESP: a flexible and compressed format for IPsec/ESP", Daniel Migault, Tobias Guggemos, Daniel Palomares, 2014-03-03, IPsec/ESP has been designed to secure IP packets exchanged between two nodes. IPsec implements security at the IP layer which makes security transparent to the applications, as opposed to TLS or DTLS that requires application to implement TLS/DTLS. As a result, IPsec enable to define the security rules in a similar way one establishes firewall rules. One of the IPsec's drawbacks is that implementing security on a per packet basis adds overhead to each IP packet. Considering IoT devices, the data transmitted over an IP packet is expected to be rather small, and the cost of sending extra bytes is so high that IPsec/ESP can hardly be used for IoT as it is currently defined in RFC 4303. This document defines Diet-ESP, a protocol that compress and reduce the ESP overhead of IPsec/ESP so that it can fit security and energy efficient IoT requirements. Diet-ESP use already existing mechanism like IKEv2 to negotiate the compression format. Furthermore a lot of information, already existing for an IPsec Security Association, are reused to offer light negotiation in addition to maximum compression. "FlowQueue-Codel", Toke Hoeiland-Joergensen, Paul McKenney, Dave Taht, Jim Gettys, Eric Dumazet, 2014-03-03, This memo presents the FQ-CoDel hybrid packet scheduler/AQM algorithm, a critical tool for fighting bufferbloat and reducing latency across the Internet. 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. "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", Simon Josefsson, 2014-03-03, This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. This is an update of RFC 5801 that relaxes the requirement for channel binding support and mutual authentication in the underlying GSS-API mechanism. "Lightweight mutual authentication for CoAP (WIP)", Abhijan Bhattacharyya, Soma Bandyopadhyay, Arijit Ukil, Tulika Bose, Arpan Pal, 2014-03-03, This draft presents a work-in-progress on a challenge-response based lightweight authentication scheme to mutually authenticate CoAP client and server for establishing a secure unicast communication channel. The draft discusses the generic idea behind the proposed authentication scheme, as well as presents its CoAP specific adoption. The proposed scheme has low communication overhead and can be a robust alternative against the usual DTLS based connection initiation scheme with PSK. "MOBIKEv2: MOBIKE extension for Transport mode", Daniel Migault, Daniel Palomares, 2014-03-03, MOBIKE [RFC4555] is the IKEv2 Mobility and Multihoming Protocol and as been defined only for IPsec Security Association using the tunnel mode. This document describes MOBIKEv2 that extends MOBIKE [RFC4555] for IPsec Security Associations using also transport mode. "Protocol Layering in HTTP/2", Wenbo Zhu, Takeshi Yoshino, Roberto Peon, 2014-03-03, This document discusses requirements that will allow HTTP/2 to be used as a generic transport for use cases beyond the basic HTTP/1.1 request-response messaging. "IANA Allocation of Experimental Code Points for PIM Join Attribute and PIM Encoded-Source Address", william.atwood@concordia.ca, Stig Venaas, 2014-03-03, This memo asks the IANA to allocate experimental code points to the PIM Join Attribute Types register and the Encoded-Source Address Encoding Type Field register. "Service Forwarding Label", Changcheng Huang, Jiafeng Zhu, Peng He, 2014-03-03, New services such as network function virtualization (NFV), service chaining, and application-centric traffic steering bring new opportunities for network providers and service providers. This internet draft defines a new Layer 5 packet header format called Service Forwarding Label (SFL) and procedures which can be used as a universal label to differentiate various services and forward packets based on different service requirements. "Use of S/MIME Encryption Function in Enterprises", Youki Kadobayashi, ando_Tw, Kohei Kasamatsu, Satoru Kanno, 2014-03-03, In this document, we provide a method for enterprises to utilize and operate the use of S/MIME to handle highly confidential information. "IETF Anti-Harassment Procedures", Pete Resnick, Adrian Farrel, 2014-04-29, 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 version of this document is provided as a continued point for discussion and does not represent the firm opinions of the authors. Furthermore, the ideas presented in this document have not been fully discussed and reviewed by the IESG. "I2RS Security Considerations", Susan Hares, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Qin Wu, Ahmed Abro, Salman Asadullah, Joel Halpern, Eric Yu, 2014-06-17, This presents an expansion of the security architecture found in the i2rs architecture. "Opportunistic Encryption for the Locator/ID Separation Protocol (LISP)", Ed, 2014-03-04, The Locator/ID Separation Protocol (LISP), allows the creation of VPNs between routing locators (RLOCs). As LISP encapsulated packets are generally expected to traverse publically routed spaces, it is desirable to encrypt the payloads of these packets, to protect them from pervasive surveillance attacks. This document describes a methodology to encrypt LISP encapsulated packets, as they traverse between RLOCs. For a full description of LISP, please consult [RFC6830]. "Network Coding Taxonomy", Victor Firoiu, Brian Adamson, Vincent Roca, Cedric Adjih, Josu Bilbao, Frank Fitzek, Antonia Masucci, Marie-Jose Montpetit, 2014-03-05, This document summarizes a recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms with unique names in order to avoid ambiguities in future Network Coding IRTF and IETF documents. This document is intended to be in- line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups. "MPEG Media Transport Protocol (MMTP)", Imed Bouazizi, 2014-03-04, 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. "Impersonation Naming Attribute for the Generic Security Services Application Programming Interface (GSS-API)", Nicolas Williams, 2014-03-04, This document describes a method for impersonation of one principal by another. Relying parties are expected to apply policy to decide which impersonation attempts they accept. Trusted third parties may provide assistance in evaluating policy. The proposed system fails safe: applications that do not support it see their peers as the impersonators, not the impersonated principals. "Using Wildcard A and AAAA Resource Records in the DNS for Per-User Host- Based Services", Viktor Dukhovni, Nicolas Williams, 2014-03-04, This document describes how the use of wildcard A and AAAA resource records (RRs) in the Domain Name System (DNS), optionally coupled with self-service key management for host names that match the wildcards, to create per-user services. This memo describes what should be a best current practice. "TE extensions to OSPF for GMPLS control of Flex-Grid Networks", Iftekhar Hussain, Rajan Rao, Marco Sosa, Abinder Dhillon, 2014-03-04, This document specifies the extension to TELINK LSA of OSPF routing protocol [RFC4203] [3] in support of GMPLS [1] for flex-grid networks [2]. This draft is a renamed version of ''draft-dhillon-ccamp-super- channel-ospfte-ext-06.txt'' [11]. To align with ITU terminology, references to super-channel have been removed in the title & other parts of the document. "Double Network Layer solution as IPng", Shi Li, 2014-03-04, This document describes a new proposal for IPng. Compared to IPv6, this proposal has bigger address space, and most importantly, is HIGHLY COMPATIBLE with IPv4. "An IETF with Much Diversity and Professional Conduct", Dave Crocker, Narelle Clark, 2014-03-04, The process of producing today's Internet through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. Historically participation in the IETF and its antecedent was almost entirely composed of well-funded, American, white, male engineers. No matter the intentions of the participants, such a narrow demographic distorts group dynamics, both in management and in personal interactions. In the case of the IETF, group interaction style can often demonstrate 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 paper discusses the nature and practicalities of IETF attention to its diverse participation and to the requirement for professional demeanor. "Proxy Mobile IPv6 with Mobility Session Redirection", Seil Jeon, Young-Han Kim, 2014-03-05, This specification defines an extension for mobility session redirection in Proxy Mobile IPv6 networks, enabling the sessions to be redirected between local mobility anchors over a PMIPv6 domain. "The Resource Public Key Infrastructure (RPKI) to Router Protocol", Randy Bush, Rob Austein, 2014-03-07, In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. "IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils, Brian Field, Ida Leung, 2014-06-09, 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. "Privacy and Networking Functions", Jari Arkko, 2014-03-06, This paper discusses the inherent tussle between network functions and some aspects of privacy. There is clearly room for a much improved privacy in Internet communications, but there are also interesting interactions with network functions, e.g., what information networks need to provide a service. Exploring these limits is useful to better understand potential improvements. "Authenticated Content Promise Extension for (D)TLS", Martin Thomson, 2014-03-06, This document describes an extension to Transport Layer Security (TLS) and Datagram TLS (DTLS) that enables the negotiation of a promise to protect session content from modification and eavesdropping by third parties. "Email client should show information if email send using telnet by strangers", pradeep xplorer, 2014-03-25, This document describes the need for information in the email client whether the recieved email was send by telnet to a mail server by strangers and a way to configure the email clients to not to show such emails.Emails of financial importance should not be send using this method.SPAMMING is a distraction.If i get 10 SPAM for one authentic email, then i would not be able to pay attention to the authentic email. "Email provider should provide email owner an audit log", pradeep xplorer, 2014-03-06, 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. "An HTTP client device should have a clearance level.", pradeep xplorer, 2014-03-06, This document describes the need for an HTTP client to have a clearance level.So if i have a Website with Topsecret information only an HTTPclient device with a clearance above Topsecret should be able to see files from that server.A Browser or a desktop can be considered an HTTP client. "DNS Privacy with a Hint of Onion", Roy Arends, Joe Abley, Joao Damas, 2014-03-06, The Domain Name System (DNS) has no inherent capability to protect the privacy of end users. The data associated with DNS queries and responses can be observed by intermediate systems, and such observations could provide a source of metadata relating to end user behaviour. This document describes an approach which separates the data in DNS queries and responses from the identity of the DNS resolver used by DNS clients. This approach does not address privacy concerns between a stub resolver and a recursive resolver. This approach imposes no requirement for modification of authority servers, and does not depend upon widespread deployment of DNSSEC signing or validation. "Client Authentication Request Extension for (D)TLS", Martin Thomson, 2014-03-08, This document describes an extension to Transport Layer Security (TLS) and Datagram TLS (DTLS) that allows a client to indicate that it wants to provide a client certificate. "Client Authentication over TLS Connection Header", Martin Thomson, 2014-03-08, This document defines an HTTP header field that can be added to a response to indicate to a client that a response will only be provided over a TLS connection, and only if the client has provided a certificate on that connection. "Compression of Record and Handshake Headers for Constrained Environments", Shahid Raza, Hossein Shafagh, Olivier Dupont, 2014-03-09, This document describes header compression mechanisms for the Datagram Transport Layer Security (DTLS) [RFC6347] based on the encoding scheme standardized in [RFC6282]. The DTLS Record Header (RH), Handshake Header (HH), and optionally handshake message headers are compressed using Next Header Compression (NHC) defined in [RFC6282]. This document neither invalidates any encoding schemes proposed in 6LoWPAN [RFC6282] nor compromises the end-to-end security properties provided by DTLS. This document aims to increase the applicability of DTLS and, thus, CoAPs [draft-ietf-core-coap-18] in constrained environments. "Solution for Site Multihoming in a real IP environment", Shyam Bandyopadhyay, 2014-06-18, This document provides a solution for Site Multihoming of stub networks in a real IP environment. Each user interface in a customer network will 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 intermediar", Andrew Allen, 2014-03-11, 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. "The 'urn:social' Namespace", James Snell, 2014-03-12, This document defines a Uniform Resource Name (URN) namespace identifier for generating URN's suitable for use in a variety of social constructs. "Delay Tolerant Networking Security Key Management - Problem Statement", Fred Templin, 2014-03-12, 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 operational limitations of the protocol. This document therefore presents a problem statement for security key management in DTNs. "Delay Tolerant Networking Header Integrity Assurance - Problem Statement", Fred Templin, 2014-03-12, Delay/Disruption Tolerant Networking (DTN) introduces a network model for environments in which communications may be subject to long delays and/or intermittent connectivity. A Bundle Protocol (BP) has been designed to accommodate data communications in such challenging environments through multi-hop store-and-forward message propagation, where each hop may be required to store bundles of data for long periods of time. It is therefore essential that bundles with corrupted headers (e.g., the primary bundle block) be detected as soon as possible in order to avoid resource exhaustion due to accidental or malicious factors, and to permit timely retransmission. In this document, we discuss the need for a hop-by-hop integrity assurance as a means for encouraging suitable solutions. "Delay Tolerant Networking Time Synchronization - Problem Statement", Fred Templin, 2014-03-12, Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. DTN nodes include timestamps in the bundles of data they send so that correspondents can identify the bundles and determine the length of time they have been in the system. However, there is currently no specified strategy for synchronizing the clocks between DTN nodes. This document therefore presents a problem statement for time synchronization in DTNs. "krb5 based key derivation for rxkad", Benjamin Kaduk, 2014-03-12, This document describes two extensions to the rxkad security class for the RX RPC protocol, rxkad-k5 and rxkad-kdf. rxkad currently relies on the Kerberos Key Distribution Center to support single-DES encryption types, which are increasingly disabled by default in Kerberos implementations. This document provides a framework for rxkad to support long-term service keys with strong enctypes (rxkad-k5), and a key derivation procedure to allow Kerberos session keys with strong enctypes to be used with rxkad (rxkad-kdf). "Anonymous ECDH Ciphersuites with Modern Ciphers and Cipher Modes for Transport Layer Security (TLS)", Nicolas Williams, 2014-03-13, This document requests the registration and allocation of codepoints for new Transport Layer Security (TLS) ciphersuites with modern ciphers and cipher modes. "Unique Identifiers in DHCP options enable device tracking", Christian Huitema, 2014-03-12, 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. This document reviews these options and proposes solutions for better management. "Segmentation Offloading Extension for VXLAN", hzhou8@ebay.com, Chengyuan Li, 2014-05-02, Segmentation offloading is nowadays common in network stack implementation and well supported by para-virtualized network device drivers for virtual machine (VM)s. This draft describes an extension to Virtual eXtensible Local Area Network (VXLAN) so that segmentation can be decoupled from physical/underlay networks and offloaded further to the remote end-point thus improving data-plane performance for VMs running on top of overlay networks. "TLS Certificate Identity Verification Procedure for SMTP MTA to MTA Connections", Stephan Friedl, Tom Kaupe, Sriram Gorti, 2014-03-13, This document describes TLS server identity verification procedure for Message Transfer Agent (MTA) to Message Transfer Agent connections in an SMTP email network, with specific guidance on identity verification steps associated with delegated email services. This document is intended to supplement the identify verification procedures described in [RFC6125]. "Considerations for a New pNFS Layout Type", Tom Haynes, 2014-04-29, 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 may be troublesome for those trying to specify new Layout Types. "The 2NN Patch HTTP Status Code", Mark Nottingham, 2014-03-13, This document specifies the 2NN Patch HTTP status code to allow servers to perform partial updates of stored responses in client caches. "Stability of Interior Routing and Load Balancing Techniques", Curtis Villamizar, 2014-03-14, This is an informational document intended to outline what is known about routing stability of interior gateway protocols (IGPs), traffic engineering techniques (TE) used in MPLS, and load balancing techniques. Known stable and unstable conditions provide bounds of known behavior. Network operators and equipment suppliers have relied heavily on operational experience as existence proof of instability or evidence of apparent stability. Between the bounds of known stable and unstable behavior there may be conditionally stable protocols and deployment scenarios. There is some discussion of the difficulty of mathematical stability proof for some techniques and a challenge to the research community. "JavaScript Object Notation (JSON) Text Sequences", Nicolas Williams, 2014-03-14, This document describes the JSON text sequence format and associated media type. "A new form of network technology- Wisdom Network", Xiaona Li, 2014-03-16, In this paper, a new form of network technology with wisdom, the wisdom network, is presented, defined and described. It is a collaborative network; it can distinguish, judgment;it can process information resources into knowledge, achieve mastery of knowledge; it can self- manage, self-repair and self-adapt; it can predict the future changes of network environment and people's emotional state. Network can self- learn,self-grow and self-innovate. The network has humanChengke abiChengty of observation,understanding people's emotions and intentions. On the base of the definition of wisdom network, we describe the basic characteristics and architecture of it, and detailedly depict wisdom framework of Wisdom network, finally, we propose a method to implement wisdom network, namely, multi-agent technology. "Single SOcket Dual Allocation with TURN", Paal-Erik Martinsen, Justin Uberti, Oleg Moskalenko, 2014-03-17, This draft describes a simple method for allocating one IPv4 and one IPv6 relay address from a single ALLOCATE request to the TURN server. This saves local ports on the client, reduces the number of candidates gathered by the client, and reduces the number of messages sent between the client and the TURN server. "Consensus Cryptographic Algorithms", Phillip Hallam-Baker, 2014-03-17, This document specifies conformance criteria for choices of cryptographic algorithms. Conformance with this document establishes that an implementation supports the community consensus for choice of cryptographic algorithms at the time of publication and that the implementation can interoperate with other implementations compliant with the specified criteria. "SDP codepoints for gateway control", Albrecht Schwarz, Christian Groves, 2014-04-11, 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 usaged at call or bearer control level. Such SDP codepoints are collected by this RFC with the purpose of registration with IANA. "An architectural framework of the internet for the real IP world", Shyam Bandyopadhyay, 2014-03-18, 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. "An approach of transportation of RT packets through IP switch based networks to achieve the best performance.", Shyam Bandyopadhyay, 2014-03-18, This document intends to find out the size of an IP packet at which VoIP applications will produce the best result. It emphasizes the physical phenomenon because of which ATM networks perform better than the IP switch based networks and tries to come out with an approach by which IP switch based network can perform as good as ATM network for the processing of real time traffic. "Pervasive Encryption as a Countermeasure to Pervasive Monitoring", Stephen Kent, 2014-03-18, This document was prepared as part of the IETF response to concerns about "pervasive monitoring" as articulated in [I-D.farrell-perpass- attack]. It begins by exploring terminology that has been used in IETF standards (and in academic publications) to describe encryption and key management techniques, with a focus on authentication vs. anonymity. Based on this analysis, it propose a new term, "pervasive encryption" (PE) to describe a goal for IETF security protocols, one countermeasure to pervasive monitoring. "A TCP Authentication Option Extension for Payload Encryption", Joseph Touch, 2014-05-12, 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. "DNS query name minimisation to improve privacy", Stephane Bortzmeyer, 2014-05-19, This document describes one of the techniques that could be used to improve DNS privacy (see [I-D.bortzmeyer-dnsop-dns-privacy]), a technique called "qname minimisation". Discussions of the document should currently take place on the dns- privacy mailing list [dns-privacy]. "ECC Brainpool Curves for DNSSEC", Joern-Marc Schmidt, Johannes Merkle, Manfred Lochter, 2014-03-21, This document specifies the use of ECDSA with ECC Brainpool curves in DNS Security (DNSSEC). It comprises curves of three different sizes. "DNS Privacy and Censorship: Use Cases and Requirements.", Phillip Hallam-Baker, 2014-05-09, This document describes use cases and requirements arising from privacy an free speech concerns in the DNS. "HMAC-SHA-2 Authentication Protocols in USM for SNMP", Johannes Merkle, Manfred Lochter, 2014-05-06, This memo specifies new optional HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. "Service Chain Header", Cathy(Hong) Zhang, Louis Fourie, Ron Parker, Myo Zarny, 2014-05-09, This document describes a service chaining header format and encapsulation mechanism that is used to facilitate the forwarding of data packets along the service function chain path. This header also allows for the transport of metadata to support various service chain related functionality. "Compression of IPsec AH and ESP Headers for Constrained Environments", Shahid Raza, Simon Duquennoy, Goran Selander, 2014-03-24, This document describes the header compression mechanisms for the 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 using the free bits in the IPv6 Extension Header encoding. "Ethernet LDP( Label Distribution with out IP and routing protocols)", sudhin jacob, 2014-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. "Benchmarking Methodology for OpenFlow SDN Controller Performance", Bhuvaneswaran Vengainathan, Anton Basil, Vishwas Manral, 2014-03-25, This document discusses and defines a number of tests that may be used to measure the performance characteristics of OpenFlow (OF) SDN controller. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. "There should be a concept of mask applied to HTTP URLs.", pradeep xplorer, 2014-03-26, This document describes the need for an HTTP client browser to be able to use masks and create masks by logic and drag and drop in the browser and see them as pulldown menu in the browser while viewing URLs or URIs?. "PCE support for Maximizing Diversity", Dhruv Dhody, Qin Wu, 2014-06-03, 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. "Segment Routing Use Cases", Clarence Filsfils, Pierre Francois, Stefano Previdi, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Igor Milojevic, Rob Shakir, Saku Ytti, Wim Henderickx, Jeff Tantsura, Sriganesh Kini, Edward Crabbe, 2014-03-27, Segment Routing (SR) leverages the source routing and tunneling paradigms. 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. Segment Routing can also be applied to IPv6 with a new type of routing extension header. "A Common Layer 3 Interface for MANET", Jack Shaio, Caleb Lo, donb@mitre.org, 2014-03-27, 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. "Multiple multicast addressing architecture", Robert Chodorek, 2014-03-28, 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. "Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS", Daniel Gillmor, 2014-04-28, Traditional discrete logarithm-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 establishing a registry of DH parameters with known structure and a mechanism for peers to indicate support for these groups. "6LoPLC: Transmission of IPv6 Packets over IEEE 1901.2 Narrowband Powerline Communication Networks", Daniel Popa, Jonathan Hui, 2014-03-30, This document updates [RFC 4944], "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", and [RFC 6282], "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", and specifies the 6LoPLC technology: the transmission of IPv6 packets over IEEE 1901.2 narrowband powerline communication networks. "Interface to a Packet Switching Element (IPSE)", Rex Fernando, Sami Boutros, Dhananjaya Rao, 2014-03-30, 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. "YANG Data Model for Generic Operations, Administration, and Maintenance (OAM)", Tissa Senevirathne, Norman Finn, Deepak Kumar, Samer Salam, Carlos Pignataro, 2014-06-10, This document presents YANG Data model for OAM. It provides a protocol-independent and technology-independent abstraction of key OAM constructs. These abstractions span OAM configuration and operational data; they promote uniformity between OAM technologies and support nested OAM workflows (i.e., performing OAM functions at different layers through a unified interface). "Segment Routing in IP RAN use case", Bhumip Khasnabish, fangwei hu, 2014-03-31, Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through a controlled set of instructions, called segments, by pre-pending the packet with an SR header. 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 one 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. This document introduces the segment routing in IP Radio Access Network (IP RAN, mobile backhaul network) use case. Additional requirements to support segment routing in the IP RAN scenarios are discussed. "Guidelines and Registration Procedures for New URI Schemes", Dave Thaler, Tony Hansen, Ted Hardie, Larry Masinter, 2014-03-31, This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. "Opportunistic Security as a Countermeasure to Pervasive Monitoring", Stephen Kent, 2014-04-09, This document was prepared as part of the IETF response to concerns about "pervasive monitoring" (PM) as articulated in [I-D.farrell-perpass-attack]. It begins by describing the current criteria (discussed at the STRINT workshop [STRINT]) for addressing concerns about PM. It then examines terminology that has been used in IETF standards (and in academic publications) to describe encryption and key management techniques, with a focus on authentication vs. anonymity. Based on this analysis, it propose a new term, "opportunistic security" to describe a goal for IETF security protocols, one countermeasure to pervasive monitoring. "Brotli Compressed Data Format", Jyrki Alakuijala, Zoltan Szabadka, 2014-05-16, 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. "Anonymizing and privatizing requests and responses in the DNS", Wesley Hardaker, 2014-04-01, This document discusses the type of architecture necessary to make DNS requests not just private between parties, but functionally anonymous so that the only entity that knows who made the request is the source entity itself. "The SDP RTCP Extension", Harald Alvestrand, 2014-04-01, This document specifies an RTCP extension that allows SDP information to be carried over an RTP session. This extension obivates the need for a separate negotiation channel, thereby avoiding the risk of desynchronization between the SDP session description and the RTP session state. "Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)", Michael Jones, John Bradley, Hannes Tschofenig, 2014-06-26, 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. "OpFlex Control Protocol", Michael Smith, Mike Dvorkin, Youcef Laribi, Vijoy Pandey, Pankaj Garg, Nik Weidenbacher, 2014-04-02, The OpFlex architecture provides a distributed control system based on a declarative policy information model. The policies are defined at a logically centralized policy repository (PR) and enforced within a set of distributed policy elements (PE). The PR communicates with the subordinate PEs using the OpFlex Control protocol. This protocol allows for bidirectional communication of policy, events, statistics, and faults. This document defines the OpFlex Control Protocol. "CoAP Endpoint Identification", Oliver Kleine, 2014-04-02, The Constrained Application Protocol (CoAP) is an application layer protocol for constrained devices (e.g.low power, few memory) and networks (e.g. lossy, low bandwidth) which relies on UDP on the transport layer. With CoAP it is often the case, that message exchanges need to extend the common request/response pattern, e.g. for seperate responses. This holds, e.g. for CON requests that are confirmed by the server with an empty ACK and answered later with a seperate response. According to the CoAP specification the request/ response matching is realized using a unique pair of server address and token per client. Due to the mobile nature of some devices. e.g. smartphones, they are often assigned new IP addresses because of a network change. Thus, the IP address of a CoAP server might change during an ongoing conversion. This draft proposes a method to assign each communication partner with an identifier (endpoint ID) which replaces the IP address as (partial) key to relate requests and responses. Besides the common seperate responses, the proposed method is also useful to handle IP address changes, e.g. during an ongoing observation ([observe]) or a blockwise transfer ([block]). "Applications aware LDP Targeted Session", Santosh Esale, Raveendra Torvi, Chris Bowers, 2014-04-02, Recent Targeted LDP applications such as Remote LFA and BGP auto discovery FEC 129 pseudowire may automatically establish a targeted LDP session to any LSR in the core network. The sender LSR has information about the targeted applications to administratively control initiation of the session. However the receiver LSR has no such information to control the acceptance of this session. This document defines a mechanism to advertise Targeted Application Capability during session initialization. As the receiver LSR becomes aware of targeted LDP applications, it may establish a limited number of sessions for certain applications. In addition, each targeted application is mapped to LDP FEC Elements to advertise only necessary LDP FEC label bindings over the session. "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Phil Hunt, Justin Richer, William Mills, Prateek Mishra, Hannes Tschofenig, 2014-06-26, 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. "Passive DNS - Common Output Format", Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern, 2014-04-04, This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. "Peer-specific Redirection for Traversal Using Relays around NAT (TURN)", Brandon Williams, Tirumaleswar Reddy, 2014-06-10, This specification describes a peer-specific redirection method that allows the TURN server to redirect a client for the purpose of improving communication with a specific peer without negatively affecting communication with other peers. "BGP Link-Local Next Hop Capability", Vipin Kumar, Pradosh Mohapatra, Dinesh Dutt, Mike Valentine, 2014-04-06, This document proposes a new BGP capability to allow route resolution over IPv6 link-local next hop. It eliminates the requirement of assigning a global IPv6 address for the next hop. "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership", Mark Smith, 2014-04-07, For each of their IPv6 unicast or anycast addresses, nodes join a Solicited-Node multicast group, formed using the lower 24 bits of the address. This group membership can be used by routers to further mitigate the Neighbor Discovery cache Denial of Service attack. "Dynamic Path Selection Requirements", Arun, 2014-04-07, The high availability puzzle can be resolved by building in resiliency to network designs. Whilst active/backup routing schemes are sufficient to create redundancy with low convergence times the following deficiencies and customer demands are not addressed comprehensively. "Uniform information with a hybrid naming (hn) scheme", Hong-Ke Zhang, Wei Quan, Jianfeng Guan, Changqiao Xu, Fei Song, 2014-04-07, This document defines a hybrid naming scheme for unifying all kinds of information. As many proposals of novel network architectures emerge, 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 naming format defined is to identify different routing information uniformly. The format adopts a hybrid structure including hierarchical component, flat component and attribute component, providing great compatibility and advantages. "IPv6 Universal Extension Header", Fernando Gont, Will, Suresh Krishnan, Hagen Pfeifer, 2014-04-08, In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport- layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and specifies a new IPv6 Extension Header - the Universal Extension Header - that overcomes the aforementioned problem, while enabling the extensibility of IPv6. Finally, this document formally obsoletes RFC 6564. "Dynamic Path Selection use-cases", Arun, 2014-04-08, Dynamic Path Selection is framework for offloading certain applications traffic that are considered not-so-critical by the network administrator on to a secondary paths ( The paths that are not considered best by routing protocols ). The frame work for implementing such a offloading mechanism is clearly defined in the draft draft-arumuganainar-rtgwg-DPS-requirements-00. This draft describes the use cases for DPS in brief. "Layer 4 Path preference negotiation for DPS", Arun, 2014-04-08, This document is a supporting draft to draft-arumuganainar-rtgwg-DPS- Requirements-00. The DPS draft talks about high level architecture to implement dynamic path selection based on application. The DPS draft suggests the implementation to be done in three steps: 1) DPS Signaling: Here participating routers communicate with each other to exchange application related information 2) Profile Based Filter: This section describes how packets can be classified and filtered 3) DPS Routing Frame Work: This ensures that separated traffic remains separated through out the network While overall architecture is still valid, this draft suggests an enhancement to the DPS Signaling component. The currently implemented technique uses BGP for the signaling requirements. Whilst this is good for certain cases, applications that can be off loaded to the secondary link are pre-decided. It restricts behavior from responding to dynamic network conditions. For example, a network administrator would want to off load some of the non-critical applications over the secondary link, however when there is acute congestion within the network, they might want the router to behave aggressively by off loading more applications to the secondary circuit. Yet while doing so there should not be any asymmetric routing on the network. Since BGP is essentially a control plane protocol, it is not aware of what is happening on the network in the forwarding plane, hence there is a need to do the signaling in the forwarding plane. This drafts suggest one such mechanism. Here the idea is to exchange the Path Preference information at layer 4 level. Such signaling could happen during TCP connection establishment phase. When done this way, a decision can be taken for each of the session and hence making it more dynamic than the one that can achieved through BGP. "Chunked Progress extension to HTTP", Loic Nageleisen, 2014-04-08, This document describes Chunked Progress, an extension to Transfer-Encoding: Chunked as defined in RFC2616 [RFC2616]. Chunked Progress introduces a backwards-compatible, RFC2616 compliant method to notify the client of transfer advancement in situations where the server has knowledge of progress but cannot know the resource size ahead of time. "Security Mechanism Names for Media", Peter Dawes, 2014-04-09, Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in RFC 3329 [4]. 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. "EAP-based Authentication Service for CoAP", Rafael Lopez, Raul Sanchez, 2014-04-09, This document describes an authentication service that uses EAP transported by means of CoAP messages with two purposes: o Authenticate two CoAP endpoints. o Bootstrap key material to protect CoAP messages exchanged between them. "Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)", Martin Thomson, 2014-04-09, 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. "TLS Crypto Constructs for Version 1.3", Michael StJohns, 2014-04-09, This document describes a set of replacements for the TLS cryptographic constructs for use with TLS1.3 and later. The constructs used in versions of TLS 1.2 and prior have some issues with respect to secure implementation using generic security hardware. "SFC Header Mapping for Legacy SF", Haibin Song, Lucy Yong, Yuanlong Jiang, 2014-04-16, SFC (Service Function Chaining) is used to manipulate service functions with easy creation, updating and deletion. A service function chain goes through a list of ordered service function instances. One assumption of this document is that legacy service function instances can participate in the service chain. They are not aware of the SFC header, nor interpret it. This document provides a mechanism between a Service Forwarding Entity (SFE) and a Service Function Instance (SFI), to identify the SFC header associated with a packet that is returned from an SFI, without SFC header being explicitly carried in the wired protocol between SFE and SFI. "Autonomic Networking Use Case for Home Networks", Brian Carpenter, 2014-05-18, This document describes a use case for autonomic networking in home network scenarios. It is one of a series of use cases intended to illustrate requirements for autonomic networking. "An IRTF Primer for IETF Participants", Spencer Dawkins, 2014-05-26, This document provides a high-level description of things to consider when bringing new research into the Internet Research Task Force (IRTF). It targets Internet Engineering Task Force (IETF) participants, emphasizing the differences in expectations between the two organizations. "Network Transport Circuit Breakers", Gorry Fairhurst, 2014-05-05, This note explains what is meant by the term "network transport circuit breaker" (CB). It describes the needs for circuit breakers when using network tunnels, and other non-congestion controlled applications. It defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. "JSON Web Key (JWK) Thumbprint", Michael Jones, 2014-04-10, This specification defines a means of computing a thumbprint value (a.k.a. digest) of JSON Web Key (JWK) objects analogous to the "x5t" (X.509 Certificate SHA-1 Thumbprint) value defined for X.509 certificate objects. This specification also registers the new JSON Web Signature (JWS) and JSON Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) member name "jkt" (JWK SHA-256 Thumbprint) for holding these values. "WebRTC Dependencies", Cullen Jennings, 2014-04-11, 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-04-11, This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. It also updates RFC 5802 in minor ways. "DNS Search List Processing", Daniel Migault, 2014-04-11, Domain Names can be Qualified or Unqualified Domain Names. Qualified Domain Names are resolved over the public DNS infrastructure, whereas Unqualified Domain Names are resolved using search lists. How search lists are generated and interpreted varies from one application to another and from one operating system to another. This makes Unqualified Domain Name resolution unpredictable, non deterministic, and as such neither reliable nor stable. In addition, there is neither clear rules to define whether a name is a Qualified or an Unqualified Domain Name. This also contributes in making the naming resolution unreliable, as the resolution of a given name can result in different responses. As a consequence, most resolution systems currently end with a "try and error" strategy. More specifically, according to some system dependent heuristics, a resolver initiates an Unqualified (resp. Qualified) Domain Name resolution, and, in case of a NXDOMAIN response, fails back in a Qualified (resp. Unqualified) Domain Name resolution. Such strategies were acceptable as the probability of collision between domains within search list and those published in the public DNS infrastructure remains low. In the context of the generalization of Top Level Domain, this assumption is not acceptable anymore, resulting in an unreliable and unstable naming resolution. This document describes how search list should be generated and interpreted. Then, it describes how resolvers distinguish between Qualified and Unqualified Domain Names as well as how to resolve them. "Metropolitan Beacon System (MBS) ICD", jvogedes@nextnav.com, 2014-04-25, This document describes the air interface of the Metropolitan Beacon System (MBS) system. MBS provides a high precision, reliable, consistent positioning system indoors and in urban canyons, where GNSS solutions are degraded or denied. In addition to the high 2-D accuracy, the MBS system architecture also provides for high resolution and accuracy in the vertical dimension, with the aid of embedded sensors. MBS technology provides a very fast time to first fix (TTFF), on the order of ~6 seconds under cold start conditions. Similar to GNSS, MBS technology allows computation of the location on the device without any network dependence thus enabling a wide variety of standalone applications. "Just because it's an ID doesn't mean anything... at all...", Warren Kumari, 2014-04-17, Anyone can publish an Internet Draft. This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. "Adobe's RTMFP Profile for Flash Communication", Michael Thornburgh, 2014-06-24, This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. "EDNS Version 1 (EDNS(1))", Mark Andrews, 2014-04-15, It is impracticable to deploy new EDNS options, with EDNS version 0, on a global scale due to inconsistent server behaviour in deployed servers when a EDNS option is present in the query. Most existing EDNS option deployment has been small scale between essentially consenting implementations. When EDNS options were added to every outgoing recursive query made it became clear that trial and error to discover the level of EDNS version 0 support was not practicable. This document request that EDNS version 1 be assigned so that consistent well defined behaviour can be seen when a EDNS option is present. "PCP as a Traffic Classifier Control Protocol", Mohamed Boucadair, 2014-04-16, This document specifies how PCP (Port Control Protocol) can be used as a classifier control protocol. "The IPv6 Flow Label within a RPL domain", Pascal Thubert, 2014-05-19, This document present how the Flow Label can be used inside a RPL domain as a replacement to the RPL option and provides rules for the root to set and reset the Flow Label when forwarding between the inside of RPL domain and the larger Internet, in both direction. This new operation saves 44 bits in each frame, and an eventual IP- in-IP encapsulation within the RPL domain that is required for all packets that reach outside of the RPL domain. "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Alfredo Pironti, Adam Langley, Marsh Ray, 2014-04-18, The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the client and server identities. 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 renegotiation after 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. "Transport Layer Security (TLS) Resumption Indication Extension", Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Alfredo Pironti, Adam Langley, Marsh Ray, 2014-04-18, When a TLS session is resumed via an abbreviated handshake, the knowledge of the master secret is used to implicitly mutually authenticate the two peers. However, an attacker can synchronize two different TLS sessions, so that they share the same master secret, breaking the resumption authentication property. This specification defines a TLS extension that cryptographically binds the resumption abbreviated handshake with its original session, thus preventing this attack. "TCP Extended Data Offset Option", Joseph Touch, Wesley Eddy, 2014-05-05, 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 that have evolved. This document updates RFC 793 with an optional TCP extension to that space and explains why such extensions cannot be used in the initial SYN of a connection. "RADIUS Extensions for IP Port Configuration and Reporting", Dean Cheng, Jouni Korhonen, Mohamed Boucadair, Senthil Sivakumar, 2014-04-18, This document defines three new RADIUS attributes. For device 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, NAT64, Provider WiFi Gateway, etc. This document does not make any assumption about the deployment context. "Service Function Chaining Use Case for SPRING", Xiaohu Xu, Zhenbin Li, Himanshu Shah, 2014-06-17, This document describes a particular use case for SPRING where the Segment Routing mechanism is leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). "Host Identification Problem in Service Function Chaining Use Cases", Li Xue, Behcet Sarikaya, 2014-04-21, The purpose of this document is to present host identification problem due to the address and prefix sharing in service function chaining. So far we have identified this problem in the two use cases of the parental control service and offloading service but it is likely that more use cases can be identified. "SACM Architecture Based on TNC Standards", Atul Shah, llorenzin@juniper.net, 2014-04-21, The Security Automation and Continuous Monitoring (SACM) Working Group aims to develop open standards for managing endpoint posture assessment. This document shows how the Trusted Network Connect standards can be used to meet this goal. "Registry Specification for Mandatory Access Control (MAC) Security Label Formats", David Quigley, Jarrett Lu, Tom Haynes, 2014-04-21, In the past Mandatory Access Control (MAC) systems have used very rigid policies which were hardcoded into the particular protocol and platform. As MAC systems are more widely deployed additional flexibility in mechanism and policy is required. Where traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include technologies such as type enforcement. Due to the wide range of policies and mechanisms it has proven through past efforts to be virtually impossible to accomodate all parties in one security label format and model. To allow multiple MAC mechanisms and label formats in a network, this document proposes a registry of label format specifications. This registry contains several identifiers to accomodate both integer and string preferences and associates those identifiers with an extensive document outlining the exact syntax and use of the particular label format. "Hypernetwork Model and Architecture for Deep Space Information Networks", Long Zhang, luqieranya@163.com, Wenjing Cao, Wei Huang, Yan Ding, 2014-04-21, The increasing world-wide demands in deep space scientific missions, such as Lunar, Mars and other Planetary Exploration, along with the rapidly growing advances in space communication technologies have triggered the vision of so called future Deep Space Information Networks (DSINs). The coined DSIN paradigm is envisioned to be an integrated high speed self-organizing hypernetwork consisting of the terrestrial ground-based information networks and the outer space- based entities to provide maximum network capacity. In this document, the problem of network infrastructure and architecture for DSINs is investigated. Taking into account the major challenges or characteristics affecting link, networking, transport, and security design of DSINs, this document employs hypergraph theory to construct network infrastructure and node architecture of space optical switching, and further presents a five-layered hypernetwork model of DSINs to enhance network connectivity. Combining with the benefits in interconnection and interoperability of heterogeneous challenged networks, brought by the well-known Delay-and Disruption-Tolerant Networking (DTN) architecture, this document proposes a novel architecture of DSINs from two levels including Layered Protocol Stack and Management Plane. The proposed architecture preliminarily achieves the basic concepts and the relevant mechanisms of wisdom network, and the performance and quality of service (QoS) of DSINs are thereby improved. "Application Layer Protocol Negotiation (ALPN) for Session Traversal Utilities for NAT (STUN)", Prashanth Patil, Tirumaleswar Reddy, Gonzalo Salgueiro, Marc Petit-Huguenin, 2014-04-22, An Application Layer Protocol Negotiation (ALPN) label for the Session Traversal Utilities for NAT (STUN) protocol is defined in this document to allow the application layer to negotiate STUN within the Transport Layer Security (TLS) connection. The STUN ALPN protocol identifier applies to both TLS and Datagram Transport Layer Security (DTLS). "Routing Documentation Language", Per Bilse, 2014-04-22, This document provides an introduction to RDL (Routing Documentation Language). RDL is a high level language capable of describing BGP topology as well as both inter- and intra-AS route filtering and announcements, and can be compiled to actual router configuration detail for a number of vendors' equipment. "DNS over DTLS (DNSoD)", Tirumaleswar Reddy, Dan Wing, Prashanth Patil, 2014-04-22, 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. "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution", John Bradley, Phil Hunt, Michael Jones, Hannes Tschofenig, 2014-06-26, 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. "Segment Routing Architecture", Clarence Filsfils, Stefano Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Igor Milojevic, Rob Shakir, Saku Ytti, Wim Henderickx, Jeff Tantsura, Edward Crabbe, 2014-06-06, 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. "PCE-based SFC Architecture in SR Networks", Xiaohu Xu, Jianjie You, Himanshu Shah, Luis Contreras, 2014-06-22, Service Function Chaining (SFC) provides a flexible way to construct services. When applying a particular service function chain to the traffic, the traffic needs to be steered through an ordered set of service functions in the network. This ordered set of service functions in the network, referred to as a Service Function Path (SFP), is an instantiation of the service function chain in the network. Segment Routing (SR) technique can be leveraged to steer the traffic through the SFP in SR networks. This document describes a PCE-based SFC architecture in which the PCE is used to compute a service function path (i.e., instantiate a service function chain) in SR networks. "A Method for Signing an HTTP Requests for OAuth", Justin Richer, John Bradley, Hannes Tschofenig, 2014-04-24, 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. "The IMAP UIDONLY Extension", Arnt Gulbrandsen, 2014-04-25, Opening a large mailbox in IMAP can take mailbox; 30 seconds is realistic if the mailbox contains ten million messages. Most of that time is needed to number the messages consecutively. This extension provides a way to avoid having to number the messages consecutively. "Autonomic Networking Use Case for Auto Address Management", Sheng Jiang, Brian Carpenter, Qiong, 2014-04-28, This document describes a use case for autonomic address management in large-scale networks. It is one of a series of use cases intended to illustrate requirements for autonomic networking. "SIP URI Inter Operator Traffic Leg parameter", Christer Holmberg, Jan Holm, Roland Jesske, Martin Dolly, 2014-06-13, In telecommunication networks, the signalling path between a calling user and a called user can be partioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The 'iotl' parameter is defined in order to fulfil requirements from the 3rd-Generation Partnership Project (3GPP), but it can also be used in other network environments. "PCEP Extensions for SFC in SR Networks", Xiaohu Xu, Jianjie You, Himanshu Shah, Luis Contreras, 2014-06-22, [I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC architecture in which the PCE is used to compute service function paths in SR networks. Based on the above architecture, this document describes extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and instantiate service function paths in SR networks. "BGP Link-State Extensions for SR-based SFC", Xiaohu Xu, 2014-04-28, The Segment Routing mechanism can be leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). The link-state IGPs (i.e., IS-IS and OSPF) have been extended to advertise service information including services and the corrresponding service segment identifiers. For the purpose of building service function paths which span across IGP areas, or even across ASes, this draft defines extensions to the BGP Link-state address-family to carry service information including services and the corrresponding service segment identifiers. "Protecting Internet Key Exchange (IKE) Implementations from Denial of Service Attacks through Client Puzzles", Yoav Nir, 2014-04-30, This document describes an enhancement to the Stateless Cookie mechanism described in RFC 5996. Whereas the original mechanism prevents denial-of-service (DoS) attacks that use multiple spoofed source addresses, the mechanism here is effective against a distributed denial of service attack (DDoS), where the attackers use their own source address. This is accomplished by requiring proof of work by the Initiator before allocating resources at the Responder. "Using Client Puzzles to Protect TLS Servers From Denial of Service Attacks", Yoav Nir, 2014-04-30, This document proposes a mechanism for mitigating denial of service (DoS) and distributed denial of service (DDoS) attacks on TLS servers. Attackers are limited in their ability to cause resource waste on the server by requiring proof of work by the client before these CPU resources are expended. "Framework for Service Function Instances Restoration", Linda Dunbar, Andy Malis, 2014-04-30, This draft describes the framework of protection and restoration of Service Chain Instance Path when some instances on the path fail or need to be replaced. "A DKIM Profile to Enable Message Forwarding", John Levine, 2014-05-02, Some mail systems have been observed to use authentication schemes the domain name in the From: header as a security key, in combination with DKIM, an approach works poorly in connection with forwarders that edit messages. This document describes a profile of DKIM intended to improve interoperation of DKIM with such schemes. "Host Identification Problem in Service Function Chaining Use Cases", Behcet Sarikaya, Li Xue, 2014-05-02, 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. "Mapping 802.11 QoS in a PMIPv6 Mobility Domain", John Kaippallimalil, Rajesh Pazhyannur, Parviz Yegani, 2014-05-02, This document provides a model for enabling end to end QoS in systems where there is a 802.11 based wireless system coupled with a PMIPv6 mobility domain consisting a local mobility anchor and mobility access gateway. This enables QoS policing and labeling of packets in a consistent manner on the 802.11 link between the MN and the AP as well as the link between the MAG and the LMA. To enable this, the document specifies mapping between QoS parameters on the 802.11 link and the QoS Mobility options in the PMIPv6 domain. "Encoding claims in the OAuth 2 state paramater using a JWT", John Bradley, 2014-05-04, This draft provides a method for a client to encode one or more elements encoding information about the session into the OAuth 2 "state" paramater. "Explicitly Authenticated Proxy in HTTP/2.0", Salvatore Loreto, John Mattsson, Robert Skog, Hans Spaak, Gus Bourg, Dan Druta, Mohammad Hafeez, 2014-05-04, This document proposes the definition of an Explicitly Authenticated Proxy as intermediary of normally unprotected "http://" URI scheme requests and responses of HTTP2 traffic. An Explicitly Authenticated Proxy is a message forwarding agent that is selected, with explicit user's consent, and configured by the user agent to receive exclusively "http" URI scheme requests and attempt to satisfy those requests on behalf of the user agent. A client is connected to an Explicitly Authenticated Proxy through an authenticated TLS secured connection. This document describes a method for a user agent to automatically discover and authenticate, and for an user to provide consent for an Explicitly Authenticated Proxy. This enables proxied communication to be encrypted and authenticated, explicitly acknowledged by the user agent and visible to the server end point. "BFD Proxy for Connections over Monitored Links", Brian Snyder, Nobo Akiya, 2014-05-05, This document describes a Bidirectional Forwarding Detection (BFD) proxy mechanism to allow intermediate networking equipment (ex: Satellite HUB/Modem) to intercept BFD packets and to generate BFD packets to relay the health of connection monitored links. Note that this is an informational document that does not propose any changes to the BFD protocol. "JSON Log Format (JSON-L)", Phillip Hallam-Baker, 2014-05-06, A log file format based on the JSON encoding is described. "DNS-SD Extensions for Service Function Discovery", Xiaohu Xu, 2014-05-06, Service Function Chaining (SFC) [I-D.quinn-sfc-arch] provides a flexible way to construct services. When applying a particular service function chain to the traffic classified by the SFC classifier, the traffic needs to be steered through an ordered set of Service Functions (SFs) in the network. This document describes how to discover SFs in the SR network [I-D.xu-spring-sfc-use-case] based on DNS-SD [RFC6763]. "The Architecture for Ubiquitous Green Community Control Network", Mike Cheng, Frankey Feng, 2014-05-07, In this document, it identifies gateways for field-bus networks, data storages for archiving and developing data sharing platform, and application units to be important system components for developing digital communities: i.e., building-scale and city-wide ubiquitous facility networking infrastructure. The standard defines a data exchange protocol that generalizes and interconnects these components (gateways, storages, application units) over the IPv4/v6-based networks. This enables integration of multiple facilities, data storages, application services such as central management, energy saving, environmental monitoring and alarm notification systems. "Security for Ubiquitous Green Community Control Network", Mike Cheng, Frankey Feng, 2014-05-07, This document describes enhanced security management function for the protocol defined in "Ubiquitous Green Community Control Network", specifies security requirements, defines system security architecture, gives a standardized description of authentication, authorization, along with security procedures and protocols. This standard can avoid unintended data disclosure to the public and unauthorized access to resources, while providing enhanced integrity and confidentiality of transmitted data in the ubiquitous green community control network. "Consistent Control Mechanism in Software Defined Network", Lieguang Zeng, Ye Zhou, Mao Yang, Yong Li, Depeng Jin, Li Su, 2014-05-07, This document introduces a consistent control mechanism in the framework of Software Defined Network (SDN), which is one method to achieve forwarding and control element separation. In detail, this mechanism uses a centralized control element to control multiple forwarding elements. "Minimalist Port Control Protocol Proxy", Markus Stenberg, 2014-05-07, This document describes a minimalist PCP proxy function needed within the homenet architecture. It is notably a subset of a general PCP proxy. "OSPF extensions to advertise S-BFD Target Discriminator", Manav Bhatia, Trilok Ranganath, Carlos Pignataro, Sam Aldrin, 2014-05-07, 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. "Interactions of I2RS with NETCONF and YANG", Tom Petch, 2014-05-08, This memo looks at some possible interactions between the requirements of I2RS and the current capabilities (and data models) of YANG and NETCONF. "Advertising S-BFD Discriminators in IS-IS", Les Ginsberg, Nobo Akiya, Mach Chen, 2014-05-08, This document defines a means of advertising one or more S-BFD Discriminators using the IS-IS Router Capability TLV. "Client Authentication over New TLS Connection", Martin Thomson, 2014-05-08, This document defines an HTTP authentication scheme that can be added to an error response to indicate to a client that a successful response will only be provided over a new TLS connection, and only if the client has provided a certificate on that connection. "Encoding claims in the OAuth 2 state parameter using a JWT", John Bradley, Torsten Lodderstedt, Hans Zandbelt, 2014-05-22, 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. "COllaborative NETwork (CONET) Gap Analysis", Sheng Jiang, Rong Zhang, 2014-05-08, In order to efficiently distinguish ICPs' traffic, a new network operation model - COllaborative NETwork is proposed. The traffic recognization is based on traffic of ICPs' products actively carries collaborative identifiers that both ISPs and ICPs reach consensus in a coordination way. This document analyzes the tecnical gap between the current network functions and required network capability to support COllaborative NETwork. "Network Technology- Wisdom Network", Xianwei Zhou, 2014-05-09, In this paper, a new form of network technology with wisdom, the wisdom network, is presented, defined and described. It is a collaborative network; it can distinguish, judgment;it can process information resources into knowledge, achieve mastery of knowledge; it can self- manage, self-repair and self-adapt; it can predict the future changes of network environment and people's emotional state. Network can self- learn,self-grow and self-innovate. The network has humanChengke abiChengty of observation,understanding people's emotions and intentions. On the base of the definition of wisdom network, we describe the basic characteristics and architecture of it, and detailedly depict wisdom framework of Wisdom network, finally, we propose a method to implement wisdom network, namely, multi-agent technology. "Autonomic Networking Use Case for Network Bootstrap", Michael Behringer, Max Pritikin, Steinthor Bjarnason, 2014-05-09, This document describes a use case for a specific autonomic functionality: Securely bootstrapping new devices into a network, without the need for pre-staging. The goal is to illustrate a requirement from network operators, and to illustrate how autonomic approaches can solve this use case. "Private-DNS", Phillip Hallam-Baker, 2014-05-09, This document describes Private DNS, a transport security mechanism for the DNS protocol. The mechanism may be employed to secure communication between a client and its resolver or between a resolver and an authoritative server. Service binding including key exchange is effected using the JSON Service Connect (JCX) Protocol. DNS protocol messages are wrapped in a new framing protocol. "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding", Julian Reschke, 2014-05-10, 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. "Service Function Path Optimization", Surendra, Jim Guichard, Paul Quinn, Joel Halpern, 2014-05-10, 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 optimal SFCs with improved latencies, reduced resource consumption and better user experience. This document describes the rationale, techniques and necessary protocol extensions to achieve such optimization. "Generic Event Delivery Using HTTP Push", Martin Thomson, 2014-05-12, A simple scheme for the delivery of realtime events to clients is described. This scheme uses HTTP/2 push. "USer Invokable Actions on Desktops to install/copy Websites", pradeep xplorer, 2014-05-12, 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. "Web PKI Operations: Revocation and Status", Phillip Hallam-Baker, David Chadwick, 2014-05-13, This document describes the certificate status mechanisms supported in the Web PKI "Topology Independent Fast Reroute using Segment Routing", Pierre Francois, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, 2014-05-13, This document presents a Fast Reroute (FRR) approach aimed at providing link and node protection of node and adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. We accommodate the FRR discovery and selection approaches in order to establish protection over post-convergence paths from the point of local repair, dramatically reducing the operator's need to control the tie- breaks among various FRR options. "The Entity Category SAML Entity Metadata Attribute Types", Ian Young, Leif Johansson, Scott Cantor, 2014-05-15, This document describes a SAML entity attribute which can be used to assign category membership semantics to an entity, and a second attribute for use in claiming interoperation or support for entities in such categories. This document is a product of the Research and Education Federations (REFEDS) Working Group process. "Using Transport Layer Security for http URIs", Martin Thomson, 2014-05-14, This describes how HTTP URIs can be resolved using Transport Layer Security (TLS). "Hypervisor to NVE Control Plane Requirements", Li Yizhou, Lucy Yong, Lawrence Kreeger, Thomas Narten, David Black, 2014-05-15, This document describes the control plane protocol requirements when NVE is not co-located with the hypervisor on a server. A control plane protocol (or protocols) between a hypervisor and its associated external NVE(s) is used for the hypervisor to populate its virtual machines states to the NVE(s) for further handling. This document illustrates the functionalities required by such control plane signaling protocols and outlines the high level requirements to be fulfiled. Virtual machine states and state transitioning are summarized to help clarifying the needed requirements. "DNS Update Based Service Function Update", Xiaohu Xu, 2014-05-16, In a Service Function Chaining (SFC)-enabled domain, the Domain Name System (DNS) can be used as a mechanism for Service Function (SF) auto-discovery [I-D.xu-dnssd-sf-discovery]. Since the information associated with SF instances (e.g., capacity and current load) would change dynamically, the information associated with SF instances which is stored in the DNS sever needs to be updated accordingly. This document describes how to use the DNS UPDATE mechanism [RFC2136] to dynamically update the corresponding Resource Records (RRs) for SF instances. "Hypertext Transfer Protocol: Improved HTTP Caching", Chris Drechsler, 2014-05-16, This document describes an improved HTTP caching method which can be applied in addition to the standard caching behavior described in [Part6]. It defines the associated header field that controls this improved caching mechanism and a modified caching operation which is slightly different to one in [Part6]. "WebRTC Codec Preferences", Kiran Guduru, 2014-05-16, WebRTC working group prefers mandatory to implement codecs inside the browser to achieve guaranteed interoperability between two WebRTC peers. WebRTC allows browser implementors to support vendor specific codecs apart from mandatory codecs. This document explains the way 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, 2014-05-17, We present a problem description for authentication and authorization in constrained-node networks, i.e. networks which contain some devices with severe constraints on power, memory, and processing resources. "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, 2014-05-19, 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. "ForCES inter-FE Consistent Control Scheme", Lieguang Zeng, Ye Zhou, Mao Yang, Yong Li, Depeng Jin, Li Su, 2014-05-19, This document addresses the inter-FE consistent control problem for ForCES in software-defined network (SDN), and proposes an inter-FE consistent control scheme through dynamic match-field selection. In detail, the control element (CE) analyzes the similarities and differences between both the old and rules. Then, CE dynamically determines appropriate match fields and, correspondingly, generates a set of transitional flow entries. After that, it deletes the old flow entries and writes the new ones. Finally, the consistent control is achieved after deleting the transitional flow entries. This scheme guarantees the inter-FE consistent control. "SXS Confirmation Protocol (SXS-Confirm)", Phillip Hallam-Baker, 2014-05-19, JSON Confirmation Protocol (JCP) is a three party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes. "Topology Independent Fast Reroute using Segment Routing", Pierre Francois, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, 2014-05-20, This document presents a Fast Reroute (FRR) approach aimed at providing link and node protection of node and adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. We accommodate the FRR discovery and selection approaches in order to establish protection over post-convergence paths from the point of local repair, dramatically reducing the operator's need to control the tie- breaks among various FRR options. "Detecting NVO3 Overlay Point-to-Multipoint Data Plane failures", Liang Xia, Hao Weiguo, Greg Mirsky, 2014-05-20, This draft refers to P2MP LSP ping, and describes NVO3 overlay P2MP ping mechanisms by extending the existing NVO3 overlay P2P ping mechanisms for applying to NVO3 overlay P2MP path in order to simplify implementation and network operation. "OmniBroker Publication Protocol", Phillip Hallam-Baker, 2014-05-22, 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. "X509.v3 certificate extension for authorization of device ownership", Michael Richardson, 2014-05-22, This document details an X.509 extension to provide authorization and indication of ownership of a constrained device containing 802.1AR IDevID. "Application Enabled Collaborative Networking: Problem Statement and Requirements", Peng Fan, Hui Deng, Mohamed Boucadair, Tirumaleswar Reddy, Charles Eckel, 2014-05-23, Identification and treatment of application flows are important to many application providers and network operators. They often rely on these capabilities to deploy and/or support a wide range of applications. These applications, and the packet flows they generate and consume, may have specific connectivity requirements that can be met if made known to the network. Historically, this functionality has been implemented to the extent possible using heuristics, which inspect and infer flow characteristics. Heuristics may be based on port ranges, network separation (e.g. subnets or VLANs, Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI). But many application flows in current usages are dynamic, adaptive, time- bound, encrypted, peer-to-peer, asymmetric, used on multipurpose devices, and have different priorities depending on direction of flow, user preferences, and other factors. Any combination of these properties renders heuristic based techniques less effective and may result in compromises to application security or user privacy. "ACTN Use-case for Virtual Network Operation for Multiple Domains in a Single Operator Network", Diego Lopez, 2014-05-25, This document provides a use-case that addresses the need for facilitating the application of virtual network abstractions to network operation. These abstractions shall create a virtualized environment supporting operators in viewing and controlling different domains (at any dimension: applied technology, administrative zones, or vendor-specific technology islands) as a single virtualized network. Such an approach will facilitate the deployment of NFV (Network Function Virtualization) mechanisms, and accelerate 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 considers the application of these abstractions within the network of a single operator. "Segment Routing Centralized Egress Peer Engineering", Clarence Filsfils, Stefano Previdi, Keyur Patel, Ebben Aries, shaw@fb.com, Daniel Ginsburg, Dmitry Afanasiev, 2014-05-26, 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, 2014-05-26, Cloud computing is rapidly gaining importance, not only because of being ubiquitous, but also, due to ease of management of hugely increasing data, specially, multimedia contents. The next era is going to be of cloud federation, in which services would be brought up to the user through multiple clouds, creating an Inter-Cloud computing environment. On the other hand, increase in multimedia content requires much better service provisioning, responsiveness, and efficient transcoding. Thoroughly designing the architecture of Media Cloud Inter-Cloud Computing is today's requirement. This document focuses on this important issue and presents architectural fundamentals and key concerns in Media Cloud Inter-Cloud Computing. "Segment Routing Egress Peer Engineering BGPLS Extensions", Stefano Previdi, Clarence Filsfils, Saikat Ray, Keyur Patel, 2014-05-26, 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 BGPLS 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. "The Session Initiation Protocol (SIP) OAuth", Rifaat Shekh-Yusef, Victor Pascual, 2014-05-26, The Session Initiation Protocol (SIP) uses a challenge-response framework to authenticate the user, but it does not have an authorization framework to control the user's access to various services in the system. This document defines an authorization framework for SIP that is based on the OAuth 2.0 framework. "A DNS Resource Record for Confidential Comments (NOTE RR)", Evan Hunt, Dan Mahoney, 2014-05-28, While the DNS zone master file format has always allowed comments, there is no existing mechanism to preserve comments once the zone has been loaded into memory or converted to a binary representation. This note proposes a new "NOTE" RR type, which is stored alongside zone data and may be included in zone transfers, but is not returned in response to DNS queries. "RTP Payload Format for MELPe Codec", Victor Demjanenko, David Satterlee, 2014-05-27, 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, Daniel Black, 2014-06-01, 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 and Requirements for MPTCP Proxy in ISP Networks", Deng Lingli, Dapeng Liu, Tao Sun, Mohamed Boucadair, Gregory Cauchie, 2014-05-28, This document presents the use-cases and identifies requirements for ISP deployed MPTCP proxies for both Fixed and Mobile networks. "Use-cases for Collaborative LMAP", Deng Lingli, Rachel Huang, Shihui Duan, 2014-05-28, This document discusses the motivation and use-cases for collaborative LMAP practices, where multiple autonomous measurement systems collaborate together to help with UoE 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. "Carrying Routable IP Addresses in IS-IS Router Capability TLV", Xiaohu Xu, Uma Chunduri, 2014-05-28, This document proposes two new sub-TLVs of the IS-IS Router CAPABILITY TLV, called Routable IPv4 Address sub-TLV and Routable IPv6 Address sub-TLV respectively. "Advertising Service Functions Using IS-IS", Xiaohu Xu, Nan Wu, Himanshu Shah, 2014-06-17, The Segment Routing mechanism can be leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). This document describes how to advertise service functions and their corresponding characters (e.g.,service function segment ID) using IS-IS. "Advertising Service Functions Using OSPF", Xiaohu Xu, Nan Wu, Himanshu Shah, 2014-06-17, The Segment Routing mechanism can be leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). This document describes how to advertise service functions and their corresponding characters (e.g.,service function segment ID) using OSPF. Here the OSPF means both OSPFv2 and OSPFv3. "Application Enabled COllaborative NETworking Gap Analysis", Sheng Jiang, Hui Deng, Farooq Bari, Rong Zhang, Suresh Krishnan, 2014-05-29, Identification and treatment of application flows have become more and more important for network operators. In order to efficiently distinguish ICPs' traffic, coordination between ISPs and ICPs is required. IP flow identification can be based on ICPs' traffic carrying some mutually agreed identifiers. This document analyzes the technical gap between the current network functions and required network capability to enable such functionality. "Weak Trust Anchor Introduction", XiaoDong Lee, Haikuo Zhang, Nan Wang, Peng Zuo, Xiali Yan, Ce Luo, Hongtao Li, 2014-05-29, DNS Security Extensions (DNSSEC) is an effective method to provide security protection for resolvers and end users in the DNS protocols. But the DNSSEC is too aggressive for the DNS service in the poor network infrastructure, because the domain name will be invisible when large DNSSEC messages were dropped by some other network equipments, like the routers which have MTU problem or the old firewalls which do not support ENDS0. This document defines a new concept weak trust anchor which can be used on a security-aware resolver to get rid of the above problem. "Application Enabled Collaborative Networking Use Cases", Wesley George, Peng Fan, Tirumaleswar Reddy, Charles Eckel, 2014-05-29, This document describes application enabled collaborative networking use cases. Application enabled collaborative networking has applications explicitly signal their flow characteristics to the network. This provides network nodes with visibility of the application flow characteristics, which enables them to apply the correct flow treatment and provide feedback to applications. "ACTN : Use case for Multi Tenant VNO", Kenji Kumaki, Takuya Miyasaka, 2014-05-29, 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. "Weak Trust Anchor Introduction", XiaoDong Lee, Haikuo Zhang, Nan Wang, Peng Zuo, Xiali Yan, Ce Luo, Hongtao Li, 2014-05-29, DNS Security Extensions (DNSSEC) is an effective method to provide security protection for resolvers and end users in the DNS protocols. But the DNSSEC is too aggressive for the DNS service in the poor network infrastructure, because the domain name will be invisible when large DNSSEC messages were dropped by some other network equipments, like the routers which have MTU problem or the old firewalls which do not support ENDS0. This document defines a new concept weak trust anchor which can be used on a security-aware resolver to get rid of the above problem. "HTTP/2: Operational Considerations for Servers", Mark Nottingham, 2014-05-30, This document gives advice regarding performance and operability to servers deploying HTTP/2. "Actors in the ACE Architecture", Stefanie Gerdes, 2014-05-30, Constrained nodes are small 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. This document defines actors in the security architecture for authentication and authorization, analyzes the relationships between them, and describes their respective tasks and characteristics. This knowledge will then be used to derive requirements for the communication between the actors. "Distributing the DNS Root", Warren Kumari, Paul Hoffman, 2014-05-30, This document recommends that recursive DNS resolvers transfer the root zone, securely validate it and then populate their caches with the information. [[ Note: This document is largely a discussion starting point. ]] "SHA-2 Algorithms for the TCP Authentication Option (TCP-AO)", Sujeet Ammunje, Brian Weis, 2014-05-30, 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 and SHA-512 algorithms and attributes with TCP-AO. "Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)", Matt Byerly, Matt Hite, Joel Jaeggli, 2014-06-02, This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to intended destinations in ECMP load balanced, anycast network architectures. It discusses operational mitigations that can address this class of failure. "Enhancing Virtual Network Encapsulation with IPv6", Mark Smith, 2014-06-02, 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 transports. This memo suggests how IPv6's additonal capabilities may be used to enhance virtual network encapsulation. "Implementation Guidelines for parsing IPv6 Extension Headers", Panos Kampanakis, 2014-06-02, IPv6 is widely used on the internet today and is expected to be deployed more as more devices (i.e. home automation) get inter- connected. The IPv6 header format allows for the use of Extension Headers (EH). EHs could be chained together with very few existing guidelines by the IPv6 protocol on how devices should parse them, which open room for security concerns and inconsistencies. This document presents guidelines for parsing IPv6 EHs with a goal of providing a common and consistent parsing methodology for IPv6 implementers among the industry. "EZFLATE: Token-based DEFLATE Compression", Keith Morgan, Christoph Brunhuber, 2014-06-02, This specification defines EZFLATE, a token-based DEFLATE compression algorithm for secure compression within encrypted communication channels. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; "H2EZ: HTTP/2 Header Compression", Keith Morgan, Christoph Brunhuber, 2014-06-02, This specification defines the format and compression of HTTP header fields in HTTP/2. The compression is based on EZFLATE, which is a token-based DEFLATE algorithm for secure compression within encrypted communication channels. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; "table of contents for security architecture", Michael Richardson, 2014-06-03, This is a template for a security architecture. "A NETCONF Extension for Data Fragmentation", Bing Liu, Guangying Zheng, 2014-06-04, This document introduces an extension to NETCONF (Network Configuration) protocol. The extension allows NETCONF to handle large size data as fragmented RPC messages. Specifically, this document defines a new capability and relevant operations to handle the fragmentations. "TURN extension to convey flow characteristics", Dan Wing, Tirumaleswar Reddy, Brandon Williams, Ram R, 2014-06-04, TURN server and the network in which it is hosted due to load could adversely impact the traffic relayed through it. During such high load event, it is desirable to shed some traffic but TURN server lack requirements about the flows to prioritize them. This document defines such a mechanism to communicate flow characteristics from the TURN client to its TURN server. "ACTN Use-case for On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks", Kwang-koog Lee, Hosong Lee, 2014-06-24, This document provides a use-case that addresses the need for facilitating the application of virtual network abstractions and the control and management of on-demand end-to-end provisioning of connections 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 on-demand network connectivity service for a single operator. "Carrying Routable IP Addresses in OSPF RI LSA", Xiaohu Xu, Uma Chunduri, Manav Bhatia, 2014-06-04, 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 OSPF means boths OSPFv2 and OSPFv3. "NFV configuration north bound use cases", Deng Lingli, Haibin Song, Georgios Karagiannis, Evangelos Haleplidis, Barbara Martini, 2014-06-04, This specification lists some classical use cases of NFV configuration, especially those related to the north bound operation with the involvement of network function provider and the network function consumers, for example VNF installation, migration, replication, on-demand resource allocation and etc.. These use cases are only relative to the virtualization characteristics of network functions. These use cases will be used to identify the proper standard space and scope for the NFV configuration. "Virtual Network Function Configuration Architecture", Hong Zhou, Haibin Song, Fu Qiao, 2014-06-05, This document describes the architecture of NFV configuration in the provider's network through a centralized management system and focus on the virtualisation characteristics related issues. It is also a typical scenario in cloud computing environment where end users do not have to install or manage their applications on their end hosts, but can install and manage their own featured powerful software application in the cloud. This specification describes an architecture of NFV configuration. It is also applicable to other use cases with similar requirements. "Problem Statement and Architecture for Transport Independent OAM in the multiple layer network", Qin Wu, Mishael Wexler, Pradeep Jain, 2014-06-05, Operations, Administration, and Maintenance (OAM) mechanisms [RFC6291] are basic building blocks for every communication layer and technology. The current practice is that many technologies and layers have their own OAM protocols. In the current situation there is a little or no re-use of software and hardware in the existing OAM protocols. Vendors and operators waste a lot through the whole OAM life-cycle when a new technology is introduced. Integration of OAM across multiple technologies is extremely difficult. In many cases it is desirable to have a generic OAM to cover heterogeneous networking technologies. An example to this generic approach is the Bidirectional Forwarding Detection [BFD] mechanism that offers a way to monitor, troubleshoot and maintain the network and services in support multi-layer OAM independent of media, data protocols, and routing protocols. Generic OAM tools can be deployed over various encapsulating protocols, and in various medium types. An example of an environment in which a generic and integrated OAM protocol would be valuable is Service Function Chaining. A Service Function Chaining is composed by series of service Functions, that can act in different layers but providing an end-to-end chain or path from a source to destination in a given order [I.D-ietf-sfc-problem- statement]. In service function chaining environment it is necessary to provide end to end OAM across certain or all entities and involving many layers. OAM information should be exchanged between service functions in different layers while using various encapsulating protocols. In some cases OAM should cross different administration and/or maintenance domains. This document sets out the problem statement and architecture for the Generic OAM in the Service Layer Routing. This document will cover at least the basic OAM functions and information such as Connectivity Verification (CV), Path Verification and Continuity Checks (CC),Path Discovery / Fault Localization and Performance Monitoring necessary to monitor and maintain the network. "ACTN Use-case for Multi-domain Data Center Interconnect", Luyuan Fang, 2014-06-05, This document discusses a use-case for data center operators that need to interface multi-domain transport networks to offer their global data center applications and services. As data center operators face multi-domain and diverse transport technology, interoperability based on standard-based abstraction is required for dynamic and flexible applications and services. "Proposed Revised Bundle Protocol", Scott Burleigh, 2014-06-06, This Internet Draft presents a proposed modification to the Bundle Protocol Specification, including notes on the rationale underlying some of the proposed changes. "Framework of Supporting Applications Specific Multicast in NVO3", Anoop Ghanwani, Linda Dunbar, Vinay Bannai, ramki, 2014-06-06, This draft discusses the framework of supporting applications specific multicast traffic, i.e. the non ARP/ND related multicast/broadcast traffic, in a network that uses Network Virtualization using Overlays over Layer 3 (NVO3). It describes the various mechanisms and considerations that can be used for delivering those application specific multicast traffic in networks that use NVO3. "Differentiated Services (DiffServ) and Real-time Communication", Dan York, David Black, Cullen Jennings, Paul Jones, 2014-06-06, This document 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). As a result, use of different DSCPs within a single traffic flow may cause transport protocol interactions (e.g., due to reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. "Problem Statement for Application Policy on Network Functions (APONF)", Georgios Karagiannis, Will, Tina Tsou, Qiong, Diego Lopez, 2014-06-07, As more and more modern network applications grow in scale and complexity, their demands and requirements on the supporting communication network will increase. In particular, these demands require the use of specific network management and traffic policies which currently are not provided directly by the communication network to these applications. Application demands that are similar in nature can be grouped together in grouped/classified application models. This draft specifies the need for application policy on network functions (APONF) APONF protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. "APONF Architecture", Cathy Zhou, Tina Tsou, Qiong, Diego Lopez, Georgios Karagiannis, 2014-06-07, Currently, there are transport applications that have specific demands on a communication network. This document describes the APONF basic architecture, its elements and interfaces. The main APONF architecture entity is the Application-based Policy Decision (ABPD), which supports groups/classes of application models. Each of these models supports application demands that are similar in nature and therefore can be grouped/classified together. Moreover, the ABPD maps the classified application models into network capabilities, e.g., network management and traffic policies. "Delegating DKIM Signing Authority", Murray Kucherawy, Dave Crocker, 2014-06-19, 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, 2014-06-07, 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. "Here Lies Extensible Messaging and Presence Protocol (XMPP) Session Establishment", Dave Cridland, 2014-06-10, The Extensible Messaging and Presence Protocol (XMPP) historically had a Session Establishment request defined in RFC 3921 which clients were required to perform at the beginning of a session. RFC 6121 dropped this entirely. This specification reinstates it as an optional no-op to aid backwards compability, matching commonly deployed workarounds. "The Location Privacy of Wireless Sensor Networks: Attacks and Countermeasures", Lin Zhou, Jie Huang, 2014-06-09, With the related applications of wireless sensor networks getting into our lives quickly, the research of WSN is growing more and more necessary. The most significant problem which threatens the successful deployment of sensor systems is privacy, there are many protocols providing the security of news content for the WSNs. However, due to the open feature of sensor networks, context information is still in an exposed state, which makes the network be vulnerable to traffic analysis attack and hop by hop tracing back packet attack. Thus location privacy protection programs have been proposed. In this paper, we analyze and compare the existing major schemes comprehensively, meanwhile illustrate their theoretical models, principles and the advantages and disadvantages in detail. "YANG Data Model for NVO3 Operations, Administration, and Maintenance (OAM)", Tissa Senevirathne, Norman Finn, Deepak Kumar, Samer Salam, Carlos Pignataro, 2014-06-10, This document presents the YANG Data model for NVO3 OAM. The YANG Model presented in this document extends the Generic YANG model for OAM with NVO3 technology specifics. "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)", Tissa Senevirathne, Norman Finn, Deepak Kumar, Samer Salam, Liang Xia, Hao Weiguo, 2014-06-10, This document presents YANG Data model for TRILL OAM. It extends the Generic YANG model for OAM defined in [GENYANGOAM] with TRILL technology specifics. "Multicast DNS (mDNS) Threat Model and Security Consideration", Hosnieh, 2014-06-10, This document describes threats associated with extending multicast DNS (mDNS) across layer 3. "Common Joint Control of Middleboxes and Forwarding Elements", Lieguang Zeng, Jiaqiang Liu, Mao Yang, Yong Li, Depeng Jin, Li Su, 2014-06-11, Network services become increasingly multifarious. To efficiently guarantee the quality of services and fully utilize the network resources, network operators need to process the traffic flows through more fine-grained way. It is a promising way to deploy a series of middleboxes integrating various functions. However, this results in two challenges: 1) how to control such increasingly different middleboxes; 2) how can networks provide a common joint control scheme for both the middleboxes and forwarding elements. This document proposes a common joint scheme for middleboxes and forwarding elements. This scheme adopts logically centralized control method and utilizes standard control interfaces, which makes it flexible and efficient for the networks to determine the most optimizing path and the most appropriate functions in the middleboxes for traffic flows. It guarantees the quality of services and significantly improves resource utilization. "Framework for IP Passive Performance Measurements", Lianshu Zheng, Nalini Elkins, Deng Lingli, Michael Ackermann, Greg Mirsky, 2014-06-24, 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. "Layer 3 Cross-site VM Live Migration Scheme", Lieguang Zeng, Xu Yang, Mao Yang, Yong Li, Depeng Jin, Li Su, 2014-06-12, This document utilizes software-defined network (SDN) to propose a cross-site live VM migration scheme in layer 3 environment. The architecture and main components are described in detail. The components include central controller, local controller, gateway and virtual switch, which are in charge of cross-site communication management, in-site network configuration, inter-site connection and VM address resolution respectively. This scheme can implement layer 3 cross-site VM migration without using complex mechanism. "Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces", Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, 2014-06-13, This document defines an extension to the Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to describe Multipath Information for Link Aggregation (LAG) member links separately, thus allowing MPLS LSP Ping and Traceroute to discover and exercise specific paths of layer 2 Equal-Cost Multipath (ECMP) over LAG interfaces. This document updates RFC4379 and RFC6424. "On Queuing, Marking, and Dropping", Fred Baker, Rong Pan, 2014-06-13, This note discusses implementation strategies for coupled queuing and mark/drop algorithms. "Problem Statement for Internet-wide Geo-networking", Georgios Karagiannis, Alex Petrescu, Papadimitriou Dimitri, Bastiaan Wissingh, 2014-06-14, This document describes the need of intertwining of IP networking with geographical addressing. As used today, IP routing and addressing are completely unaware of geographic parameters such as coordinates or postal addresses. Possible applications of future Internet-wide geo-networking mechanisms include, but are not limited to, dissemination of IP packets to geographical areas, or precise tracking of package positions during a shipping process, with more use-cases under discussion. "UDP Usage Guidelines", Lars Eggert, Gorry Fairhurst, Greg Shepherd, 2014-06-17, The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. 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. 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, and middlebox traversal. If published as an RFC, this document will obsolete RFC5405. "Mobility with TURN", Dan Wing, Prashanth Patil, Tirumaleswar Reddy, Paal-Erik Martinsen, 2014-06-14, 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 TURN. This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. "QoE Evaluation for HTTP Adaptive Streaming", Xiaolin Deng, Guanglin Han, 2014-06-15, 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. "Datagram Transport Layer Security (DTLS) over Global System for Mobile Communications (GSM) Short Message Service (SMS)", Thomas Fossati, 2014-06-16, This document specifies the use of Datagram Transport Layer Security (DTLS) over the Global System for Mobile Communications (GSM) Short Message Service (SMS). "Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID", Roozbeh Atarius, 2014-06-16, This specification specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior. "Route Target Constrained Distribution of Routes with no Route Targets", Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2014-06-16, 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 intrest. The purpose of this document is to clarify the effect of the RTC mechanism on routes that do not have any RTs. "DKIM Conditional Signatures", John Levine, 2014-06-16, The DKIM protocol applies a cryptographic signature to an e-mail message. This specification extends DKIM to allow the specification of external conditions that must be satisfied for a signature to be valid. "Clarifications for the use of REFER with RFC6665", Robert Sparks, Adam Roach, 2014-06-16, An accepted SIP REFER method creates an implicit subscription using 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. "ACL YANG model", Dean Bogdanovic, Kiran Sreenivasa, Lisa Huang, Dana Blair, 2014-06-26, This document describes information and data model of Access Control List (ACL) basic building blocks. "Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson, Zaheduzzaman Sarker, 2014-06-26, This memo describes a rate adaptation framework for conversational video services. The solution conforms to the packet conservation principle and uses a hybrid loss and delay based congestion control algorithm. The framework is evaluated over both simulated 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. "Yang Data Model for ISIS protocol", Stephane Litkowski, 2014-06-17, This document defines a YANG data model that can be used to configure and manage ISIS protocol. "Explicit Subscriptions for the REFER Method", Robert Sparks, 2014-06-17, The 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 an extension to REFER to remove the implicit subscription and replace it with an explicit one. "A Property Types Registry for the Authentication-Results Header Field", Murray Kucherawy, 2014-06-17, [RFC7001] describes a 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 make sorting and filtering decisions. One portion of the definition in that document limits the types of authentication properties about a message to a small, fixed set. This document updates the specification to allow new property types to be declared and used. "An Extension to the Web Browser Single-Sign-On Profile for Dynamic Automated Metadata Exchange with SAML", Daniela Poehn, Stefan Metzger, Wolfgang Hommel, 2014-06-18, This document defines an extension for Dynamic Automated Metadata Exchange (DAME) of the Web Browser Single-Sign-On (SSO) Profile of the Security Assertion Markup Language (SAML) through an intermediate trusted third party. Besides integrated identity provider discovery, this enables the on-demand, user-initiated, and automated SAML metadata exchange for bi-directional pairing of provider entities, which allows technical trust establishment between Service Providers and Identity Providers without manual setup. "Software Defined Network based General Mobility Management Framework", Xinpeng Wei, Jing Yin, Dan Ni, Kaiping Xue, Sean Shen, 2014-06-18, This document proposes a general solution to support mobility management in software defined network. In this draft, we divide the controller plane into five function modules and explain the achievement of these functions separately. "Community Networks. Definition and taxonomy", Jose Saldana, Andres Arcia-Moret, Bart Braem, Leandro Navarro, Ermanno Pietrosemoli, Carlos Rey-Moreno, Arjuna Sathiaseelan, Marco Zennaro, 2014-06-18, Several communities have developed initiatives to build large scale, self-organized and decentralized community wireless networks that use wireless technologies (including long distance) due to the reduced cost of using the unlicensed spectrum. This can be motivated by different causes: Sometimes the reluctance, or the impossibility, of network operators to provide wired and cellular infrastructures to rural/remote areas has motivated the rise of these networks. Some other times, they are built as a complement and an alternative to wired Internet access. These community wireless networks have self sustainable business models that provide more localised communication services as well as providing Internet backhaul support through peering agreements with traditional network operators who see such community led networks as a way to extend their reach to rural/remote areas at lower cost. This document defines these networks, summarizes their technological characteristics and classifies them, also talking about their socio- economic sustainability models. There exist other networks, also based on sharing wireless resources of the users, but not built upon the initiative of the users themselves, nor owned by them. The characterization of these networks is not the objective of this document. "BGP Based Generic TransPort (bgpBGP)", Alvaro Retana, Russ White, Jakob Heitz, 2014-06-18, A wide array of information is being carried (or proposed to be carried) through BGP peering sessions. While this information is necessary and valid, BGP was not designed to carry blobs of information, but rather network layer reachability and information related directly to forwarding traffic from peer to peer. This document proposes a new BGP message type with a well defined structure to use BGP peering sessions for information passed from provider to provider along edge peering points, the BGP based Generic transPort (bgpBGP). This message type is designed to allow any pair of BGP speakers to transfer information within an existing session, or for BGP peering semantics to be used with multihop sessions between "information exchange speakers" within an autonomous system. The new message type is designed to provide flexibility by allowing the encoding of virtually any information within a BGP session through the use of type-length-vector formatting. "Inter Domain considerations for Constrained Route distribution", Stephane Litkowski, Jeffrey Haas, 2014-06-19, [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. "Requirements for an update to 6LoWPAN ND", Pascal Thubert, 2014-06-19, Work presented at the 6TiSCH and 6MAN working groups suggest a number of enhancements to the 6LoWPAN ND mechanism. This document elaborates on such requirements. "The Use-Case of Disseminating to Road-Side Units", Bastiaan Wissingh, Alex Petrescu, Georgios Karagiannis, Geert Heijenk, 2014-06-19, This document describes use cases related to disseminating Intelligent Transport System (ITS) information to Road-Side Units. The described use cases relate to the concept of disseminating ITS information from a back-office to vehicles as well as to the concept of disseminating ITS information from vehicles to the back-office and/or vehicles. "CDKIM Signatures", John Levine, 2014-06-19, The DKIM protocol applies a cryptographic signature to an e-mail message. This specification defines a DKIM-like signature that includes the specification of external conditions that must be satisfied for a signature to be valid. "NVO3 VDP Gap Analysis - VM-to-NVE Specific Control-Plane Requirements", Joseph Pelissier, Patricia Thaler, Paul Bottorff, 2014-06-19, [I-D.kreeger-nvo3-hypervisor-nve-cp-01] discusses requirements for Hypervisor-to-NVE Control Plane Protocol Functionality. The IEEE has developed a protocol called VSI Discovery Protocol (VDP) specified in [IEEE8021Qbg]. This protocol is intended to address the same basic problems at layer two as the Hypervisor-to-NVE protocol needs to address at layer three. Simply by adding the ability to carry layer three addresses to VDP using the extensibility features built into the protocol, VDP may be used as the Hypervisor-to-NVE Control Plane protocol. "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Jie Dong, Mach Chen, 2014-06-19, 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 refines the route distribution rules of RT-Constrain to address the hierarchical RR scenarios. "The Over-Version HTTP Response Header Field", Mark Nottingham, 2014-06-19, The 505 (HTTP Version Not Supported) status code does not clearly indicate, on its own, the scope of the assertion, nor the version(s) supported. This document introduces a new header field, "Over- Version", to indicate this information. "HTTP/2 Encoded Data", Matthew Kerwin, 2014-06-19, This document introduces a new encoded data frame for use in HTTP/2, and an associated setting parameter. "A Secure Data Aggregation Scheme Based on Key Vector Sharing in Wireless Sensor Network", Likun Wang, Liquan Chen, Jie Huang, 2014-06-19, This document specifies a secure data aggregation scheme based on key vector sharing. New key set is negotiated among sink and sensor nodes, and then each sensor node uses one key in the set to encrypt and decrypt sensory data. A key vector structure is constructed and shared among them. Since the size of the shared key vector structure is constant, the transmission overhead is saved in the proposed scheme while security is ensured. Moreover, MAC integrity mechanism is also included in the proposed scheme. The recommended scheme reduces the transmitted overhead so as to save the energy consumption of each sensor node.Meanwhile, the scheme is data-loss resilient. Distribution of this memo is unlimited. "Managing Router Identifiers during IPv4 Sunset", Peng Fan, 2014-06-20, This document describes problems of managing protocol identifiers when turning off IPv4 and migrating to IPv6 only network, with some potential solutions discussed. "An Autonomic Control Plane", Michael Behringer, Steinthor Bjarnason, Balaji BL, Toerless Eckert, 2014-06-20, In certain scenarios, for example when bootstrapping a network, it is desirable to automatically bring up a secure, routed control plane, which is independent of device configurations and global routing table. This document describes an approach for an "Autonomic Control Plane", which can be used as a "virtual out of band channel" - a self-managing overlay network, which is independent of configuration, addressing and routing on the data plane. "DHCPv6 Route Options for Source Address Dependent Routing", Behcet Sarikaya, 2014-06-20, This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes for source address dependent routing. Using these options, an operator can configure multi-homed nodes where other means of route configuration may be impractical. "Requirements for Plain Text RFCs", Heather Flanagan, 2014-06-20, This draft documents the change in requirements and layout for the plain-text RFC publication format. Editorial Note (To be removed by the 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 https://www.rfc-editor.org/mailman/listinfo/rfc-interest. "Authenticating Raw Public Keys with DANE TLSA", John Gilmore, 2014-06-20, This document standardizes how the Domain Name System can authenticate Raw Public Keys. Transport Level Security now has the option to use Raw Public Keys, but they require some form of external authentication. The document updates RFC 6698 to allow the Domain Name System to standardize the authentication of more types of keying material. "DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro, Victor Pascual, 2014-06-20, 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 Protocol (SRTP) security context setup with Datagram Transport Layer Security (DTLS) protocol. "CLUE protocol Call Flows", Roni Even, 2014-06-22, This document provides some call flows examples using the CLUE extensions for "telepresence" "TCP Parameter Dynamic Control", Haibin Song, Rachel Huang, 2014-06-22, This document describes a framework and message flows for centralized TCP parameter control, so that each end host in a network can make better use of the network resource according to the network status. A TCP Optimization Element and a TCP Optimization Agent are introduced. The message patterns include request response and subscription/notification. This mechanism can be used in network service providers' networks, as well as in data center networks. "IPv6 Prefix Length Recommendation for Routing Protocols", Mohamed Boucadair, Alex Petrescu, 2014-06-26, The length of IP prefixes to be manipulated by forwarding and routing processes is policy-based; no maximum length must be assumed by design. This document sketches a recommendation to be followed by forwarding and routing designs with regards to the prefix length. The aim is to avoid hard-coded routing and forwarding designs that exclude some IP prefix lengths. "DKIM "smooth" header canonicalization", Ale, 2014-06-23, This document describes a new canonicalization algorithm for DKIM, designed to be better able to survive transit through intermediaries. "Autonomic Networking in mobile wireless backhaul", Dean Bogdanovic, 2014-06-23, Mobile backhaul networks that utilize microwave technology in transport are suspicious to seasonal and/or meteorological changes. For those reasons throughput can vary significantly. This draft provides problem statement and how autonomic networking can be applied to the problem. "Secure Automation and Continuous Monitoring (SACM) Architecture", Nancy Cam-Winget, Brian Ford, llorenzin@juniper.net, Ira McDonald, loxx@cisco.com, 2014-06-24, This document describes an 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. "Yang Data Model for ISIS protocol", Stephane Litkowski, 2014-06-24, This document defines a YANG data model that can be used to configure and manage ISIS protocol. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 2014-06-24, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. "IPv6 Multicast in a 6rd Deployment", Behcet Sarikaya, Tina Tsou, Hui Ji, Cathy Zhou, Qiong, 2014-06-24, This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In the 6rd encapsulation solution, multicast communication is completely integrated into the 6rd tunnel. In the 6rd translation solution, the protocol is based on proxying MLD at the 6rd Customer Edge router interworking the MLD messages to IGMP messages and sending them upstream through a network which supports IPv4 multicast. The 6rd Border Relay is a multicast router and interworks the IGMP to MLD for onward propasgation toward the IPv6 multicast source. IPv6 Multicast data received at 6rd Border Relay is translated into IPv4 multicast data and and delivered through the IPv4 multicast tree downstream to the 6rd Customer Edge. The latter translates it back to IPv6 multicast data then delivers it to the hosts. "Hybrid Access Network Architecture", Nicolai Leymann, Cornelius Heidemann, Margaret Wasserman, Dacheng Zhang, 2014-06-25, In practice, people have realized that it may be difficult to update or rebuild existing copper networks when they are deployed in certain areas. At the same time, the requirements of customers on bandwidth are continually increased. This document tries to discuss the general network architectures which could be used to address this problem by bundling multiple hybrid access networks together according to the certain management policies. "Two-way Authentication for IoT", Corinna Schmitt, Burkhard Stiller, 2014-06-25, In this draft the first key idea for a full two-way authentication security scheme for the Internet of Things (IoT) based on existing Internet standards 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 [14]) and for devices with less resources (e.g., class 1 devices with ~10 KiB RAM and ~100 KiB ROM [14]). 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. "MPLS Deployments and Use Cases That Cannot be Solved By Using 20-bit Label", Katherine Zhao, 2014-06-25, The MPLS label format and encoding method are specified in [RFC3032], the label value is represented using the 20-bit space and supports up to 1 million of instances. As exponential Internet growth continues there are specific network deployment scenarios where a clear need to represent more than one million entities is required. This document describes the MPLS deployment scenarios, use cases, and requirements, where the current 20-bit label will no longer be sufficient. "PDF for an RFC Series Output Document Format", Tony Hansen, Larry Masinter, Matthew Hardy, 2014-06-26, <1> This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6989. It also discusses the use of PDF for Internet Drafts, and available or needed software tools for producing and working with PDF. "Identity-Based Signatures for MANET Routing Protocols", Christopher Dearlove, 2014-06-26, This document extends [RFC7182], which specifies a framework for, and specific examples of, integrity check values (ICVs) for packets and messages using the generalized packet/message format specified in [RFC5444]. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an identity-based signature, defined according to the ECCSI (Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption) algorithm specified in [RFC6507]. Network Time Protocol (ntp) --------------------------- "Using NTP Extension Fields without Authentication", Tal Mizrahi, Danny Mayer, 2014-01-02, The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field 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. The current definition of extension fields in NTPv4 is somewhat ambiguous regarding the connection between extension fields and the presence of a Message Authentication Code (MAC). This draft clarifies the usage of extension fields in the presence and in the absence of a MAC, while maintaining interoperability with existing implementations. "Network Time Security", Dieter Sibold, Stephen Roettger, Kristof Teichel, 2014-03-19, This document describes the Network Time Security (NTS) protocol that enables secure authentication of time servers using Network Time Protocol (NTP) or 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 [I-D.ietf-tictoc-security-requirements]. "Using NTP Extension Fields without Authentication", Tal Mizrahi, Danny Mayer, 2014-06-25, The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field 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. The current definition of extension fields in NTPv4 is somewhat ambiguous regarding the connection between extension fields and the presence of a Message Authentication Code (MAC). This draft clarifies the usage of extension fields in the presence and in the absence of a MAC, while maintaining interoperability with existing implementations. Network Virtualization Overlays (nvo3) -------------------------------------- "Problem Statement: Overlays for Network Virtualization", Thomas Narten, Eric Gray, David Black, Luyuan Fang, Lawrence Kreeger, Maria Napierala, 2013-07-31, This document describes issues associated with providing multi- tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation, so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation, so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network, and maintaining that association as the virtual machine is activated, migrated and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures. "Framework for DC Network Virtualization", Marc Lasserre, Florin Balus, Thomas Morin, Nabil Bitar, Yakov Rekhter, 2014-06-05, This document provides a framework for Data Center (DC) Network Virtualization Overlays (NVO3) and it defines a reference model along with logical components required to design a solution. "NVO3 Data Plane Requirements", Nabil Bitar, Marc Lasserre, Florin Balus, Thomas Morin, Lizhong Jin, Bhumip Khasnabish, 2014-04-15, Several IETF drafts relate to the use of overlay networks to support large scale virtual data centers. This draft provides a list of data plane requirements for Network Virtualization over L3 (NVO3) that have to be addressed in solutions documents. "Network-related VM Mobility Issues", Yakov Rekhter, Wim Henderickx, Ravi Shekhar, Luyuan Fang, Linda Dunbar, Ali Sajassi, 2014-06-02, This document describes a set of network-related issues presented by the desire to support seamless Virtual Machine mobility in the data center and between data centers. In particular, it looks at the implications of meeting the requirements for "seamless mobility". "Use Cases for DC Network Virtualization Overlays", Lucy Yong, Mehmet Toy, Aldrin Isaac, Vishwas Manral, Linda Dunbar, 2014-01-08, This document describes DC Network Virtualization (NVO3) use cases that may be potentially deployed in various data centers and apply to different applications. "Network Virtualization NVE to NVA Control Protocol Requirements", Lawrence Kreeger, Dinesh Dutt, Thomas Narten, David Black, 2014-04-23, The document "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. "NVO3 Gap Analysis - Requirements Versus Available Technology Choices", Eric Gray, Nabil Bitar, Xiaoming Chen, Marc Lasserre, Tina Tsou, 2014-02-14, This document evaluates candidate protocols against the NVO3 requirements. Gaps are identified and further work recommended. "Security Requirements of NVO3", Sam Hartman, Dacheng Zhang, Margaret Wasserman, 2014-01-24, The draft describes a list of essential requirements in order to benefit the design of NOV3 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, 2014-02-14, 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. Web Authorization Protocol (oauth) ---------------------------------- "SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", Brian Campbell, Chuck Mortimore, Michael Jones, 2014-04-28, This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "OAuth 2.0 Message Authentication Code (MAC) Tokens", Justin Richer, William Mills, Hannes Tschofenig, Phil Hunt, 2014-01-15, This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a cryptographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", Brian Campbell, Chuck Mortimore, Michael Jones, Yaron Goland, 2014-04-28, This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", Michael Jones, Brian Campbell, Chuck Mortimore, 2014-04-28, This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "JSON Web Token (JWT)", Michael Jones, John Bradley, Nat Sakimura, 2014-06-20, JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". "OAuth 2.0 Dynamic Client Registration Protocol", Justin Richer, Michael Jones, John Bradley, Maciej Machulak, Phil Hunt, 2014-05-22, This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server and the resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. "OAuth 2.0 Dynamic Client Registration Metadata", Justin Richer, Michael Jones, John Bradley, Maciej Machulak, Phil Hunt, 2014-05-22, This specification is obsolete. Its previous contents have been merged into draft-ietf-oauth-dyn-reg. "OAuth 2.0 Dynamic Client Registration Management Protocol", Justin Richer, Michael Jones, John Bradley, Maciej Machulak, Phil Hunt, 2014-05-22, This specification defines methods for management of dynamic OAuth 2.0 client registrations. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "CGN Deployment with BGP/MPLS IP VPNs", Victor Kuarsingh, John Cianfarani, 2014-04-12, This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. "Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks", Ram Krishnan, Lucy Yong, Anoop Ghanwani, So Ning, Bhumip Khasnabish, 2014-06-13, Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. "IEEE 802.11 MAC Profile for CAPWAP", Chunju Shao, Hui Deng, Rajesh Pazhyannur, Farooq Bari, Rong Zhang, Satoru Matsushima, 2014-05-05, CAPWAP defines two entities: Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example in the Split MAC mode description, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambiguous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring the WLAN. "CAPWAP Extension for 802.11n and Power/channel Autoconfiguration", Yifan Chen, Dapeng Liu, Hui Deng, Lei Zhu, 2014-05-13, 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 of Networks with Constrained Devices: Problem Statement and Requirements", Mehmet Ersue, Dan Romascanu, Jürgen Schönwälder, 2014-02-14, This document provides a problem statement, deployment and management topology options as well as the requirements for the management of networks where constrained devices are involved. "Management of Networks with Constrained Devices: Use Cases", Mehmet Ersue, Dan Romascanu, Jürgen Schönwälder, Anuj Sehgal, 2014-02-14, This document discusses the use cases concerning the management of networks, where constrained devices are involved. A problem statement, deployment options and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements". "Management Information Base for Virtual Machines Controlled by a Hypervisor", Hirochika Asai, Michael MacFaden, Jürgen Schönwälder, Keiichi Shima, Tina Tsou, 2014-02-10, 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, 2014-05-05, CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC) using CAPWAP. 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 it is desirable to encapsulate date frames to an entity different from the AC for example to an Access Router (AR). 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. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Using Only Link-Local Addressing Inside an IPv6 Network", Michael Behringer, Eric Vyncke, 2014-05-15, In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Fernando Gont, Will, Gunter Van de Velde, 2014-06-05, This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. "Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks", Fernando Gont, 2014-04-24, The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leaks. That is, traffic meant to be transferred over an encrypted and integrity protected VPN tunnel may leak out of such tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue. "Network Reconnaissance in IPv6 Networks", Fernando Gont, Tim Chown, 2014-06-14, 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. "BGP operations and security", Jerome Durand, Ivan Pepelnjak, Gert Doering, 2014-04-27, BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, TCP-AO, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 2014-06-25, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Security Extension for OSPFv2 when using Manual Key Management", Manav Bhatia, Sam Hartman, Dacheng Zhang, Acee Lindem, 2014-05-18, The current OSPFv2 cryptographic authentication mechanism as defined in RFC 2328 and RFC 5709 is vulnerable to both inter-session and intra-session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks. This draft proposes changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header. "OSPFv3 Auto-Configuration", Acee Lindem, Jari Arkko, 2014-02-10, OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred Baker, 2014-05-29, 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, 2014-06-19, Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary OSPF extensions that need to be introduced for Segment Routing. 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, 2014-06-13, 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, 2014-01-27, 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, XingFeng Jiang, Roni Even, David Bryan, Yi Sun, 2014-02-14, 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 P2P overlay networks. "Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, 2014-06-26, REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, 2014-06-14, REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. "A Usage for Shared Resources in RELOAD (ShaRe)", Alexander Knauf, Thomas Schmidt, Gabriel Hege, Matthias Waehlisch, 2014-03-03, 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. Protocol to Access WS database (paws) ------------------------------------- "Protocol to Access White-Space (PAWS) Databases", Vincent Chen, Subir Das, Lei Zhu, John Malyar, Pete McCann, 2014-04-24, Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". Audio/Video Transport Payloads (payload) ---------------------------------------- "How to Write an RTP Payload Format", Magnus Westerlund, 2014-01-13, 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, 2014-02-10, 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 Bluetooth's SBC Audio Codec", Christian Hoene, Frans Bont, 2014-03-02, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. "RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs", John Lindsay, Hartmut Foerster, 2014-02-05, This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). "RTP Payload Format for G.711.0", Michael Ramalho, Paul Jones, Noboru Harada, Muthu Perumal, Miao Lei, 2014-03-03, 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, 2014-05-28, 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) [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. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Path Computation Element (pce) ------------------------------ "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Tomonori Takeda, Adrian Farrel, Fatai Zhang, 2014-01-23, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. "Path Computation Element Protocol (PCEP) Management Information Base", Kiran Koushik, Stephan Emile, Quintin Zhao, Daniel King, Jonathan Hardwick, 2014-04-02, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. "PCEP Requirements for WSON Routing and Wavelength Assignment", Young Lee, Greg Bernstein, Jonas Martensson, Tomonori Takeda, Takehiro Tsuritani, Oscar de Dios, 2014-04-28, This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of 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. Requirements for Optical impairments will be addressed in a separate document. "PCEP extensions for GMPLS", Cyril Margaria, Oscar de Dios, Fatai Zhang, 2014-02-13, This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", Daniel King, Julien Meuric, Olivier Dugeon, Quintin Zhao, Oscar de Dios, 2014-06-03, The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. "PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", Quintin Zhao, Dhruv Dhody, Daniel King, Zafar Ali, Ramon Casellas, 2014-06-17, The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. "PCEP Extensions for Stateful PCE", Edward Crabbe, Ina Minei, Jan Medved, Robert Varga, 2014-06-24, 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, 2014-01-07, 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 Systems (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 shortest constrained 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, Vishwas Manral, Zafar Ali, George Swallow, Kenji Kumaki, 2014-03-02, In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS 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 and Packet Loss as constraints for end to end path computation. "Unanswered Questions in the Path Computation Element Architecture", Adrian Farrel, Daniel King, 2014-06-03, The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623, and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. "Applicability of a Stateful Path Computation Element (PCE)", Xian Zhang, Ina Minei, 2014-06-09, 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 de Dios, Ramon Casellas, Daniel King, 2014-02-14, 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, 2014-06-06, 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 described in [I-D.ietf-pce-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. "Secure Transport for PCEP", Diego Lopez, Oscar de Dios, Wenson Wu, Dhruv Dhody, 2014-03-11, 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 its flexibility and extensibility. "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", Edward Crabbe, Jan Medved, Ina Minei, Robert Varga, Xian Zhang, Dhruv Dhody, 2014-03-12, 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 de Dios, Xian Zhang, 2014-03-18, 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. Port Control Protocol (pcp) --------------------------- "DHCP Options for the Port Control Protocol (PCP)", Mohamed Boucadair, Reinaldo Penno, Dan Wing, 2014-04-13, This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which use of DHCPv4 or DHCPv6 apply are outside the scope of this document. "Port Control Protocol (PCP) Proxy Function", Simon Perreault, Mohamed Boucadair, Reinaldo Penno, Dan Wing, Stuart Cheshire, 2014-02-04, 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, 2014-02-08, 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 communications 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 proposes 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. "PCP Server Selection", Mohamed Boucadair, Reinaldo Penno, Dan Wing, Prashanth Patil, Tirumaleswar Reddy, 2014-04-28, The document specifies the behavior to be followed by a PCP client to contact its PCP server(s) when one or several PCP server IP addresses are configured. This document updates RFC6887. "Port Control Protocol (PCP) Extension for Port Set Allocation", Qiong, Mohamed Boucadair, Senthil Sivakumar, Cathy Zhou, Tina Tsou, Simon Perreault, 2014-05-25, 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. "PCP Anycast Address", Sebastian Kiesel, Reinaldo Penno, Stuart Cheshire, 2014-02-14, The Port Control Protocol (PCP) Anycast Address enables PCP clients to transmit signaling messages to their closest 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 Address. Protocol Independent 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, 2014-05-06, 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 addresses errata filed against RFC 4601, and removes the optional (*,*,RP) feature that lacks sufficient deployment experience. "PIM Designated Router Load Balancing", Yiqun Cai, Sri Vallepalli, Heidi Ou, Andy Green, 2014-06-11, On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a modification to the PIM-SM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed among these routers. "Explicit RPF Vector", Javed Asghar, IJsbrand Wijnands, Sowmya Krishnaswamy, Apoorva Karan, Vishal Arya, 2014-04-02, 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, Isidor Kouvelas, Jesus Arango, 2014-02-14, 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 Join Attributes for LISP Environments", Jesus Arango, Stig Venaas, Isidor Kouvelas, 2014-03-27, 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. Peer to Peer Streaming Protocol (ppsp) -------------------------------------- "Survey of P2P Streaming Applications", Gu Yingjie, Ning Zong, Yunfei Zhang, Francesca Piccolo, Shihui Duan, 2014-04-03, This document presents a survey of some of the most popular Peer-to- Peer (P2P) streaming applications on the Internet. The main selection criteria have been popularity and availability of information on operation details at writing time. In doing this, selected applications are not reviewed as a whole, but they are reviewed with main focus on the signaling and control protocol used to establish and maintain overlay connections among peers and to advertise and download streaming content. "Peer-to-Peer Streaming Peer Protocol (PPSPP)", A. Bakker, Riccardo Petrocco, Victor Grishchenko, 2014-06-17, The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both pre-recorded (on-demand) and live audio/video content. It is based on the peer- to-peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user, and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using LEDBAT for congestion control. "PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)", Rui Cruz, Mario Nunes, Gu Yingjie, Jinwei Xia, Joao Taveira, Deng Lingli, 2013-12-30, 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) ---------------------------------------------------------------- "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Peter Saint-Andre, Marc Blanchet, 2014-05-27, Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. "Preparation and Comparison of Nicknames", Peter Saint-Andre, 2014-01-23, This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON). "Mapping characters for PRECIS classes", Yoshiro Yoneya, Takahiro Nemoto, 2014-02-12, The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. Case mapping is defined because many protocols perform case-sensitive or case-insensitive string comparison and so preparation of the string is mandatory. The Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describes mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other specials that can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as an additional mapping and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. "Preparation and Comparison of Internationalized Strings Representing Usernames and Passwords", Peter Saint-Andre, Alexey Melnikov, 2014-03-25, This document describes methods for handling Unicode strings representing usernames and passwords. This document obsoletes RFC 4013. Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", Frederic JOUNAY, Yuji Kamite, Giles Heron, Matthew Bocci, 2014-06-20, This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point- to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to-Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service). "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, 2014-03-27, This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. "Explicit Path Routing for Dynamic Multi-Segment Pseudowires", Pranjal Dutta, Matthew Bocci, Luca Martini, 2014-05-09, Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit path may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths. "Pseudowire Redundancy on S-PE", Jie Dong, Haibo Wang, 2014-05-23, 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 [RFC6870] is reused. This document does not require any change to the T-PEs of MS-PW. "STP Application of ICCP", Mingui Zhang, Huafeng Wen, Jie Hu, 2014-04-23, 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. RADIUS EXTensions (radext) -------------------------- "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Stefan Winter, Mike McCauley, 2014-03-04, 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. "DTLS as a Transport Layer for RADIUS", Alan DeKok, 2014-05-08, The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, Mark Jones, 2014-03-28, RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks, as well as clarifying the usage of the EAP-Key- Name attribute and the Called-Station-Id attribute. This document updates RFC 3580 as well as RFC 4072. "The Network Access Identifier", Alan DeKok, 2014-06-17, In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. "Support of fragmentation of RADIUS packets", Alejandro Perez-Mendez, Rafael Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Diego Lopez, Alan DeKok, 2014-04-07, The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. "Larger Packets for RADIUS over TCP", Sam Hartman, 2014-04-25, 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 to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. "RADIUS Extensions for IP Port Configuration and Reporting", Dean Cheng, Jouni Korhonen, Mohamed Boucadair, Senthil Sivakumar, 2014-06-12, 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. This document does not make any assumption about the deployment context. Real-time Applications and Infrastructure Area (rai) ---------------------------------------------------- "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Roland Jesske, Keith Drage, Christer Holmberg, 2014-04-25, This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This document obsoletes RFC3455. "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. "The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header)", Hans van Elburg, Keith Drage, Mayumi Ohsugi, Shida Schubert, Kenjiro Arai, 2014-04-22, This document specifies the SIP P-Private-Network-Indication P-header used by the 3rd-Generation Partnership Project (3GPP). The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network, and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic. "A Session Identifier for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 2014-03-10, This RFC, which contains the text of an individual Internet Draft that was submitted originally to the DISPATCH Working Group, is being published now as an Informational document to provide a reference for later RFCs. The mechanism defined in this document has been widely deployed, and is being followed in a backward- compatible fashion for a new Standards Track RFC in the INSIPID Working Group. The original Abstract follows. There is a need for having a globally unique session identifier for the same SIP session, which can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middle-boxes, for the purpose of Troubleshooting. This draft proposes a new SIP header to carry such a value: Session-ID. "Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)", Gonzalo Salgueiro, Victor Pascual, Anton Roman, Sergio Garcia, 2014-04-07, RFC 7118 [RFC7118] specifies a WebSocket sub-protocol as a reliable real-time transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873 [RFC6873], with a new "Transport Flag" for such SIP WebSocket transport. RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------- "Congestion Control Requirements For RMCAT", Randell Jesup, 2014-04-18, 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 WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to ensure that this kind of traffic is congestion controlled. This document attempts to describe 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 proposals coming out of the RMCAT Working Group. "Evaluating Congestion Control for Interactive Real-time Media", Varun Singh, Joerg Ott, 2014-03-10, 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. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Multicast Protocol for Low power and Lossy Networks (MPL)", Jonathan Hui, Richard Kelsey, 2014-04-14, 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 an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to 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, Ruben Salazar, 2014-02-14, This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. "A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)", Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, Michael Richardson, 2014-06-10, This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. "ROLL Applicability Statement Template", Michael Richardson, 2014-05-08, 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 set in Home Automation and Building Control", Anders Brandt, Emmanuel Baccelli, Robert Cragie, Peter Van der Stok, 2014-05-12, The purpose of this document is to provide guidance in the selection and use of RPL protocols to implement the features required for control in building and home environments. "MPL Parameter Configuration Option for DHCPv6", Yusuke Doi, Matthew Gillmore, 2014-03-13, This draft defines a way to configure MPL parameter set via 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 parameter easily. "MPL forwarder policy for multicast with admin-local scope", Peter Van der Stok, Robert Cragie, 2014-04-08, The purpose of this document is to specify an automated policy for the routing of MPL multicast messages with admin-local scope in a border router. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ "Web Real-Time Communication Use-cases and Requirements", Christer Holmberg, Stefan Hakansson, Goran Eriksson, 2014-02-12, This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. "Overview: Real Time Protocols for Browser-based Applications", Harald Alvestrand, 2014-06-17, 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 RTCWEB 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, 2014-05-28, 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, 2014-01-21, 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, 2014-02-14, 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, 2014-02-14, 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, 2014-06-09, The Real-Time Communication in WEB-browsers working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-SRTP 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, 2014-02-13, This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. "WebRTC Data Channel Establishment Protocol", Randell Jesup, Salvatore Loreto, Michael Tuexen, 2014-06-09, The Real-Time Communication in WEB-browsers working group is charged to provide 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 RTCWEB", Harald Alvestrand, 2014-06-11, This document describes the data transport protocols used by RTCWEB, 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, 2014-06-17, To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. 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. Routing Area Working Group (rtgwg) ---------------------------------- "IP MIB for IP Fast-Reroute", Alia Atlas, Kiran Koushik, John Flick, Stephane Litkowski, 2014-06-13, 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] "Remote LFA FRR", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, So Ning, 2014-05-23, This draft describes an extension to the basic IP fast re-route mechanism described in RFC5286, that provides additional backup connectivity for point to point link failures when none can be provided by the basic mechanisms. "Advanced Multipath Use Cases and Design Considerations", So Ning, Andy Malis, Dave McDysan, Lucy Yong, Curtis Villamizar, 2014-05-14, Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. This document provides a set of use cases and design considerations for Advanced Multipath. Existing practices are described. Use cases made possible through Advanced Multipath extensions are described. "Multicast only Fast Re-Route", Apoorva Karan, Clarence Filsfils, Dino Farinacci, IJsbrand Wijnands, Bruno Decraene, Uwe Joorde, Wim Henderickx, 2014-05-15, 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 draft 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. "Microloop prevention by introducing a local convergence delay", Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Pierre Francois, 2014-02-14, This document describes a mechanism for link-state routing protocols to prevent local transient forwarding loops in case of link failure. This mechanism Proposes a two-steps convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network wide convergence. As this mechanism delays the IGP convergence it may only be used for planned maintenance or when fast reroute protects the traffic between the link failure and the IGP convergence. Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops. "Operational management of Loop Free Alternates", Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, Martin Horneffer, psarkar@juniper.net, 2014-02-12, 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, 2014-02-14, 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", psarkar@juniper.net, Hannes Gredler, Shraddha Hegde, Chris Bowers, Stephane Litkowski, Harish Raghuveer, 2014-06-24, 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. Security Automation and Continuous Monitoring (sacm) ---------------------------------------------------- "Endpoint Security Posture Assessment - Enterprise Use Cases", David Waltermire, David Harrington, 2014-04-28, 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. "Terminology for Security Assessment", David Waltermire, Adam Montville, David Harrington, Nancy Cam-Winget, 2014-05-26, This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). Sip ALerting for User Devices (salud) ------------------------------------- "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)", Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat, 2014-03-03, The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification. This document normatively updates the RFC 3261, which defines the Session Initiation Protocol (SIP): It changes the usage of the Alert- Info header field defined in the RFC 3261 by additionally allowing its use in all provisional responses to INVITE (except the 100 response). Source Address Validation Improvements (savi) --------------------------------------------- "SAVI Solution for DHCP", Jun Bi, Jianping Wu, Guang Yao, Fred Baker, 2014-05-31, This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure can be used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. "SAVI for Mixed Address Assignment Methods Scenario", Jun Bi, Guang Yao, Joel Halpern, Eric Levy-Abegnoli, 2014-05-15, This document reviews how multiple address discovery 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, 2014-06-23, The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. 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. It's 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 standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. "System for Cross-Domain Identity Management: Core Schema", Kelly Grizzle, Phil Hunt, Erik Wahlstroem, Chuck Mortimore, 2014-06-23, The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity 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 standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON format. This schema is intended for exchange and use with cloud service providers. An HTTP protocol binding document is also provided. "SCIM Use Cases", Phil Hunt, Bhumip Khasnabish, Anthony Nadalin, Kepeng Li, Zachary Zeltsan, 2014-06-18, This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). Security Area (sec) ------------------- "Simple Certificate Enrollment Protocol", Max Pritikin, Andrew Nourse, J Vilhuber, 2011-09-07, This document specifies the Simple Certificate Enrollment Protocol (SCEP), a Public Key Infrastructure (PKI) communication protocol which leverages existing technology by using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the enrollment protocol developed by VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and a Certification Authority implementations. "AES-CCM ECC Cipher Suites for TLS", David McGrew, Daniel Bailey, Matthew Campagna, Robert Dugal, 2014-02-12, This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The ciphersuites defined in this document use Elliptic Curve Cryptography (ECC), and are advantageous in networks with limited bandwidth. "PKCS #12: Personal Information Exchange Syntax v1.1", Kathleen Moriarty, Magnus Nystrom, Sean Parkinson, Andreas Rusch, Michael Scott, 2014-05-09, PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes. This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. "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. "A TLS padding extension", Adam Langley, 2014-01-08, This memo describes the a TLS extension that can be used to pad ClientHello messages to a desired size. "Using ED25519 in SSHFP Resource Records", S Moonesamy, 2014-03-27, The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. "Object Identifier Registry for the PKIX Working Group", Russ Housley, 2014-04-23, When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, it returns control of that arc to IANA, and it establishes IANA allocation policies for any future assignments within that arc. Service Function Chaining (sfc) ------------------------------- "Service Function Chaining Problem Statement", Paul Quinn, Tom Nadeau, 2014-06-24, This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. "Service Function Chaining Use Cases In Data Centers", Surendra, Cesar Obediente, Mudassir Tufail, Sumandra Majee, Claudiu Captari, 2014-05-04, 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, 2014-05-06, 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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", ramki, Anoop Ghanwani, Joel Halpern, Sriganesh Kini, Diego Lopez, 2014-06-05, 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 nodes for such flows. The benefit of this approach would be to avoid expensive Layer 7 service node processing for such flows based on dynamic decisions and improve overall performance. Secure Inter-Domain Routing (sidr) ---------------------------------- "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", Samuel Weiler, Anuja Sonalker, Rob Austein, 2014-02-12, 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. "BGP Prefix Origin Validation State Extended Community", Pradosh Mohapatra, Keyur Patel, John Scudder, David Ward, Randy Bush, 2014-02-13, As part of the origination AS validation process, it can be desirable to automatically consider the validation state of routes in the BGP decision process. The purpose of this document is to provide a specification for doing so. The document also defines a new BGP opaque extended community to carry the validation state inside an autonomous system to influence the decision process of the IBGP speakers. "Security Requirements for BGP Path Validation", Steven Bellovin, Randy Bush, David Ward, 2014-05-22, This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. "BGP Algorithms, Key Formats, & Signature Formats", Sean Turner, 2014-03-27, 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, Sean Turner, Stephen Kent, 2014-03-27, 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", Sean Turner, Keyur Patel, Randy Bush, 2014-05-23, 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. "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)", Stephen Kent, Derrick Kong, Karen Seo, 2014-04-28, This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. "Policy Qualifiers in RPKI Certificates", Andrew Newton, Geoff Huston, 2013-10-02, This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of RPKI resource certificates. "Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI)", Roque Gagliano, Terry Manderson, Carlos Martinez, 2014-02-14, The Resource Public Key Infrastructure (RPKI) depends on Relying Parties (RP) ability to access its Trust Anchors' certificate specified in the different "Trust Anchor Locator (TAL)" files and the Repository Objects located at the Certificate Authorities (CA) repositories hosted in its respective publication point. This document updates [RFC6490] by allowing multiple URI associated to a single public key in a TAL file and introduces the concept of multiple repository publication point operators for every CA in the RPKI. This document provides also recommendation for the RP behavior when analyzing signed objects that include multiple publications points. "BGPSec Considerations for AS Migration", Wesley George, Sandra Murphy, 2014-05-09, 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, 2014-02-05, 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, 2014-03-27, 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 (RPs) that verify these digital signatures. "The Resource Public Key Infrastructure (RPKI) to Router Protocol", Randy Bush, Rob Austein, 2014-04-04, In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. "Resource Certificate PKI (RPKI) Trust Anchor Locator", Geoff Huston, Samuel Weiler, George Michaelson, Stephen Kent, 2014-03-18, This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). 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, 2014-04-25, 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. SIP Recording (siprec) ---------------------- "Session Initiation Protocol (SIP) Recording Metadata", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 2014-02-11, 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, 2014-02-14, 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. "Session Initiation Protocol (SIP) Recording Call Flows", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 2014-01-13, 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, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined in the metadata draft. SIP Overload Control (soc) -------------------------- "Session Initiation Protocol (SIP) Overload Control", Vijay Gurbani, Volker Hilt, Henning Schulzrinne, 2014-03-03, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. "Session Initiation Protocol (SIP) Rate Control", Eric Noel, Philip Williams, 2014-01-06, The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. 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, 2014-03-25, 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, 2014-01-14, The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant 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, 2014-03-25, 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-04-01, The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customer sites can be assigned shared public IPv4 addresses with restricted port sets. 4rd can also support the scenarios that customer sites are assigned full public IPv4 addresses or a set of public IPv4 addresses. "Mapping of Address and Port with Encapsulation (MAP)", Ole Troan, Wojciech Dec, Xing Li, Congxiao Bao, Satoru Matsushima, Tetsuya Murakami, Tom Taylor, 2014-01-24, 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, 2014-04-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh. "DS-Lite Management Information Base (MIB)", Yu Fu, Sheng Jiang, Jiang Dong, Yuchi Chen, 2014-04-28, 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.sdo@gmail.com, Xiaohong Deng, 2014-03-14, 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-02-10, 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, 2014-04-22, 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-06-06, 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, 2014-06-13, 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, 2014-06-19, 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, Ruediger Geib, Rob Shakir, Robert Raszuk, 2014-06-26, 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'. 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", Pierre Francois, Clarence Filsfils, Bruno Decraene, Rob Shakir, 2014-05-13, 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, 2014-05-13, 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. Secure Telephone Identity Revisited (stir) ------------------------------------------ "Secure Telephone Identity Problem Statement and Requirements", Jon Peterson, Henning Schulzrinne, Hannes Tschofenig, 2014-05-09, Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall security of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack of effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. "Secure Telephone Identity Threat Model", Jon Peterson, 2014-06-11, As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi- factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched. "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, Eric Rescorla, 2014-06-20, 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. STORage Maintenance (storm) --------------------------- "RDMA Protocol Extensions", Hemal Shah, Felix Marti, Wael Noureddine, Asgeir Eiriksson, Robert Sharp, 2014-04-16, This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP RFC5040). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. SIP-TO-XMPP (stox) ------------------ "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 2014-06-10, This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions", Peter Saint-Andre, Salvatore Loreto, 2014-06-09, This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat", Peter Saint-Andre, Saul Corretge, Salvatore Loreto, 2014-06-10, 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, 2014-03-20, This document defines a bidirectional protocol mapping for use by gateways that enable the exchange of media signalling 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). Sip Traversal Required for Applications to Work (straw) ------------------------------------------------------- "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to- Back User Agents (B2BUAs)", Hadriel Kaplan, Victor Pascual, 2014-02-10, SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. "A Media-based Traceroute Function for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 2014-03-11, SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field, in order to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated which result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media- loopback mechanism, in order to test the media path when SIP sessions go through media-relaying B2BUAs. "Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)", Lorenzo Miniero, Sergio Murillo, Victor Pascual, 2014-06-20, 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 media legs 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. Sunsetting IPv4 (sunset4) ------------------------- "Gap Analysis for IPv4 Sunset", Simon Perreault, Tina Tsou, Cathy Zhou, 2014-01-16, 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. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "TCP Extensions for High Performance", David Borman, Robert Braden, Van Jacobson, Richard Scheffenegger, 2014-04-11, This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. "TCP Fast Open", Yuchung Cheng, Jerry Chu, Sivasankar Radhakrishnan, Arvind Jain, 2014-03-11, This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. "Problem Statement and Requirements for a More Accurate ECN Feedback", Mirja Kuehlewind, Richard Scheffenegger, Bob Briscoe, 2014-02-14, Explicit Congestion Notification (ECN) is an IP/TCP 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, 2014-03-21, This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support 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 either 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, 2014-02-14, This document describes a modified 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 allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", Martin Duke, Robert Braden, Wesley Eddy, Ethan Blanton, Alexander Zimmermann, 2014-04-27, This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Transporting Timing messages over MPLS Networks", Shahram Davari, Amit Oren, Manav Bhatia, Peter Roberts, Laurent Montini, 2014-04-28, This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry Timing messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting Timing messages over MPLS are defined. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation. "Precision Time Protocol Version 2 (PTPv2) Management Information Base", Vinay Shankarkumar, Laurent Montini, Tim Frost, Greg Dowd, 2014-03-12, 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. "Security Requirements of Time Protocols in Packet Switched Networks", Tal Mizrahi, 2014-06-16, As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols and the dependencies between other security services and time synchronization. "Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages", Doug Arnold, Heiko Gerstung, 2014-02-14, 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. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Cached Information Extension", Stefan Santesson, Hannes Tschofenig, 2014-02-14, 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. "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Paul Wouters, Hannes Tschofenig, John Gilmore, Samuel Weiler, Tero Kivinen, 2014-01-20, This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. "Secure Password Ciphersuites for Transport Layer Security (TLS)", Dan Harkins, Dave Halasz, 2014-03-28, 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. "Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension", Stephan Friedl, Andrey Popov, Adam Langley, Stephan Emile, 2014-03-03, This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP or UDP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. "Encrypt-then-MAC for TLS and DTLS", Peter Gutmann, 2014-06-06, This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. "The Transport Layer Security (TLS) Protocol Version 1.3", Tim Dierks, Eric Rescorla, 2014-04-17, 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. "The Transport Layer Security (TLS) Protocol Version 1.3", Tim Dierks, Eric Rescorla, 2014-04-17, 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. TURN Revised and Modernized (tram) ---------------------------------- "Problems with STUN long-term Authentication for TURN", Tirumaleswar Reddy, Ram R, Muthu Perumal, Alper Yegin, 2014-05-01, This document discusses some of the issues with STUN authentication for TURN messages. "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo Salgueiro, 2014-06-23, This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. Public Notary Transparency (trans) ----------------------------------- "Certificate Transparency", Ben Laurie, Adam Langley, Emilia Kasper, Rob Stradling, 2014-05-01, This document describes an experimental 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 certificate 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. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "TRILL: Campus Label and Priority Regions", Radia Perlman, Anil Rijhsinghani, Donald Eastlake, Ayan Banerjee, Dinesh Dutt, 2014-01-04, Within a TRILL campus, the data label (VLAN or Fine Grained Label) and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data label and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional TRILL switch feature to provide this function. "Coordinated Multicast Trees (CMT) for TRILL", Tissa Senevirathne, Janardhanan Pathangi, Jon Hudson, 2014-04-01, TRILL facilitates loop free connectivity to non-TRILL legacy networks via choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarder provides load sharing based on VLAN with an active-standby model. Mission critical operations such as High Performance Data Centers require active-active load sharing model. The Active-Active load sharing model can be accomplished by representing any given non-TRILL legacy network with a single virtual RBridge. Virtual representation of the non-TRILL legacy 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. "TRILL: ESADI (End Station Address Distribution Information) Protocol", ZTE Corporation, fangwei hu, Radia Perlman, Donald Eastlake, Olen Stokes, 2014-06-08, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multi-pathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL Switches or RBridges (Routing Bridges). ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or Fine Grained Label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible. "TRILL Smart Endnodes", Radia Perlman, fangwei hu, Donald Eastlake, Kesava Krupakaran, Ting Liao, 2014-04-21, 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. "TRILL Fault Management", Tissa Senevirathne, Norman Finn, Samer Salam, Deepak Kumar, Donald Eastlake, Sam Aldrin, Li Yizhou, 2014-05-31, This document specifies TRILL OAM Fault Management. Methods in this document follow the IEEE 802.1 CFM (Continuity Fault Management) framework and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL specific applications or where a different set of information is required other than IEEE 802.1 CFM. This document updates RFC 6325. "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", Tal Mizrahi, Tissa Senevirathne, Samer Salam, Deepak Kumar, Donald Eastlake, 2014-06-16, Performance Monitoring (PM) is a key aspect of Operations, Administration and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers, and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in TRILL networks. "TRILL: RBridge Channel Tunnel Protocol", Donald Eastlake, Li Yizhou, 2014-06-02, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism, called RBridge Channel and 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 optional extensions to RBridge Channel that provides three facilities: (1) A mechanism to send such messages between a TRILL switch and an end station in either direction, or between two end stations, when the two devices are in the same campus but not on the same link; (2) A method to support security facilities for RBridge Channel messages; and (3) A method to tunnel a variety of payload types by encapsulating them in an RBridge Channel message. This document updates RFC 7178. "TRILL: Interface Addresses APPsub-TLV", Donald Eastlake, Li Yizhou, Radia Perlman, 2014-06-02, 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, 2014-06-19, 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, 2014-01-15, 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", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, Li Yizhou, 2014-02-14, 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. "Problem Statement and Goals for Active-Active TRILL Edge", Li Yizhou, Hao Weiguo, Radia Perlman, Jon Hudson, ZTE Corporation, 2014-06-17, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow level multi-pathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high level problems and goals when providing active-active connection at the TRILL edge. "Transparent Interconnection of Lots of Links (TRILL) over IP", Margaret Wasserman, Donald Eastlake, Dacheng Zhang, 2014-03-23, 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) to provide a unified TRILL campus. Transport Area (tsv) -------------------- "Cryptographic protection of TCP Streams (tcpcrypt)", Andrea Bittau, Dan Boneh, Mike Hamburg, Mark Handley, David Mazieres, Quinn Slack, 2014-02-14, This document presents tcpcrypt, a TCP extension for cryptographically protecting TCP segments. Tcpcrypt maintains the confidentiality of data transmitted in TCP segments against a passive eavesdropper. It protects connections against denial-of-service attacks involving desynchronizing of sequence numbers, and when enabled, against forged RST segments. Finally, applications that perform authentication can obtain end-to-end confidentiality and integrity guarantees by tying authentication to tcpcrypt Session ID values. The extension defines two new TCP options, CRYPT and MAC, which are 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. The MAC option carries a message authentication code with which hosts can verify the integrity of transmitted TCP segments. 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. "TWAMP Burst Rate Measurement Features", Al Morton, Len Ciavattone, 2014-02-13, This memo describes two rate-measurement features for the core specification of TWAMP - the Two-Way Active Measurement Protocol: an optional capability where the reflector host responds with a controlled burst of test-session packets (instead of a single packet), and an optional test mode that requires the responder to measure a burst of test packets and communicate the results in truncated packet(s). Both features add the ability to control packet size in the tested direction, enabling asymmetrical packet size testing. This draft defines the modes in terms of traditional UDP test packets. Use of TCP transport instead of UDP may be desirable, but is deferred to other work. "CDNI Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Yang Yang, 2014-02-14, 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 outlines how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can facilitate Footprint & Capabilities Advertisement in a CDNI context, i.e. how the CDNI FCI can be realised with the ALTO protocol. Concrete examples of how ALTO can be integrated within CDNI request routing and in particular in the process of selecting a downstream CDN are given. The examples in this document are based on the use cases and examples currently being discussed in the CDNI WG. "Controlled Delay Active Queue Management", Kathleen Nichols, Van Jacobson, 2014-03-03, 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 gotten worse as by 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. The full buffer problem, recently christened "bufferbloat"[TSVBB2011, BB2011] has become increasingly important throughout the Internet but particularly at the consumer edge. To address bufferbloat, this document describes a general framework for controlling excessived delay in networks called Controlled Delay (CoDel) designed to work in modern networking environments as a part of the solution to bufferbloat [CODEL2012]. CoDel consists of an estimator, a setpoint, and a control loop and can be deployed in the Internet without configuration. 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. "DiffServ interconnection classes and practice", Ruediger Geib, 2014-02-14, This document proposes a limited and well defined set of QoS PHBs and PHB groups to be applied at (inter)connections of two separately administered and operated networks. Many network providers operate Aggregated DiffServ classes. This draft contains DiffServ aggregation friendly interconnection concepts. "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Rong Pan, Preethi Natarajan, Chiara Piglione, Mythili Prabhu, 2014-02-13, 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. "Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters", sbens@microsoft.com, Lars Eggert, Dave Thaler, 2014-06-05, This memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic, as implemented in Windows Server 2012. DCTCP enhances 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. Transport Area Working Group (tsvwg) ------------------------------------ "Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains", Georgios Karagiannis, Anurag Bhargava, 2014-02-14, This document specifies extensions to Generic Aggregated RSVP RFC 4860 for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. "Recommendations for Transport Port Uses", Joseph Touch, 2014-05-14, This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. "Quick Failover Algorithm in SCTP", Yoshifumi Nishida, Preethi Natarajan, Armando Caro, Paul Amer, Karen E. E. Nielsen, 2014-03-02, One of the major advantages of SCTP is supporting multi-homed communication. If a multi-homed end-point has a redundant network connections, the SCTP associations have a good chance to survive network failures by migrating traffic from inactive networks to active ones. However, if the SCTP standard is followed, there can be a significant delay during the migration. During this period, SCTP might not be able to transmit much data to the peer. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of the SCTP failover mechanism and specifies an alternative failover procedure for SCTP that improves its performance during and after failover. The procedures require only minimal modifications to the current specification. "DTLS Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, Randell Jesup, Salvatore Loreto, 2014-05-13, 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 encapsulation method described in this document, SCTP is agnostic about the protocols being used below DTLS, explicit IP addresses can not be used in the SCTP control chunks. As a consequence, the SCTP associations are single homed. "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", Michael Tuexen, Robin Seggelmann, Randall Stewart, Salvatore Loreto, 2014-05-29, This document defines two additional policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. "Generic UDP Encapsulation for IP Tunneling", Edward Crabbe, Lucy Yong, Xiaohu Xu, 2014-02-13, This document describes a method of encapsulating arbitrary protocols within GRE and UDP headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of load balancing while the payload protocol may be identified by the GRE Protocol Type. "A New Data Chunk for Stream Control Transmission Protocol", Randall Stewart, Michael Tuexen, Salvatore Loreto, Robin Seggelmann, 2014-02-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 which causes head of line blocking at the sender side. To overcome this limitation, this document adds a new data chunk to SCTP. "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Bob Briscoe, John Kaippallimalil, Patricia Thaler, 2014-03-07, 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, 2014-06-23, Many networks, such as service provider and enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per-hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. Uniform Resource Names, Revised (urnbis) ---------------------------------------- "Uniform Resource Name (URN) Syntax", Peter Saint-Andre, 2014-01-23, A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. "Uniform Resource Name (URN) Namespace Definition Mechanisms", Peter Saint-Andre, 2014-02-12, This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. "Uniform Resource Name (URN) Namespace Registration Transition", John Klensin, Juna Hakala, 2014-03-03, 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 3406bis]] to adopt 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. "Names are Not Locators and URNs are Not URIs", John Klensin, 2014-04-07, Experience has shown that identifiers associated with persistent names are quite different from identifiers associated with the locations of objects. This is especially true when such names are 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 Informational Sciences community and other users, this specification separates the syntax for URNs from the generic syntax for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating the latter specification accordingly. Using TLS in Applications (uta) ------------------------------- "Summarizing Current Attacks on TLS and DTLS", Yaron Sheffer, Ralph Holz, Peter Saint-Andre, 2014-06-23, Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DTLS. "Recommendations for Secure Use of TLS and DTLS", Yaron Sheffer, Ralph Holz, Peter Saint-Andre, 2014-06-23, Transport Layer Security (TLS) and Datagram Transport Security Layer (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and modes of operation. This document provides recommendations for improving the security of both software implementations and deployed services that use TLS and DTLS. "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, alkemade, 2014-03-27, This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120. IPv6 Operations (v6ops) ----------------------- "Enterprise IPv6 Deployment Guidelines", KK Chittimaneni, Tim Chown, Lee Howard, Victor Kuarsingh, Yanick Pouffary, Eric Vyncke, 2014-01-12, Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. "Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link", Cameron Byrne, Dan Drown, Vizdal Ales, 2014-04-01, This document describes requirements for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN link as well as two implementation examples. "Design Choices for IPv6 Networks", Philip Matthews, Victor Kuarsingh, 2014-03-06, This document presents advice on the 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. "An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices", David Binet, Mohamed Boucadair, Vizdal Ales, Cameron Byrne, Gang Chen, 2014-03-11, 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 and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [RFC7066]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. "Recommendations of Using Unique Local Addresses", Bing Liu, Sheng Jiang, 2014-02-14, This document provides guidance of how to use ULAs. It analyzes ULA usage scenarios and recommends use cases where ULA addresses might be beneficially used. "IPv6 Operational Guidelines for Datacenters", Diego Lopez, Zhonghua Chen, Tina Tsou, Cathy Zhou, Arturo Servin, 2014-02-04, This document is intended to provide operational guidelines for datacenter operators planning to deploy IPv6 in their infrastructures. It aims to offer a reference framework for evaluating different products and architectures, and therefore it is also addressed to manufacturers and solution providers, so they can use it to gauge their solutions. We believe this will translate in a smoother and faster IPv6 transition for datacenters of these infrastuctures. The document focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployment on the Data Center (DC) infrastructure. Apart from facilitating the transition to IPv6, the mechanisms outlined here are intended to make this transition as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Bing Liu, Ron Bonica, Xiangyang Gong, Wendong Wang, 2014-06-18, This document analyzes the DHCPv6/SLAAC interaction issue on host. More specifically, the interaction is regarding with the A, M, and O flags which are defined in ND protocol. Test results identify that current implementations in operating systems have varied on interpreting the flags. The variation might cause some operational issues as described in the document. "IPv6 Roaming Behavior Analysis", Gang Chen, Hui Deng, Dave Michaud, Jouni Korhonen, Mohamed Boucadair, Vizdal Ales, Cameron Byrne, 2014-01-13, This document identifies as set of failure cases encountered by an IPv6-enabled IPv6 customers in roaming scenarios. The investigations on those failed cases reveal the causes in order to notice improper configurations, equipment's incomplete functions or inconsistent IPv6 introduction strategy. "IPv4 Service Continuity Prefix", Cameron Byrne, 2014-06-11, DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. Web Security (websec) --------------------- "Public Key Pinning Extension for HTTP", Chris Evans, Chris Palmer, Ryan Sleevi, 2014-06-25, This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. Web Extensible Internet Registration Data Service (weirds) ---------------------------------------------------------- "JSON Responses for the Registration Data Access Protocol (RDAP)", Andrew Newton, Scott Hollenbeck, 2014-04-30, This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. "Registration Data Access Protocol Query Format", Andrew Newton, Scott Hollenbeck, 2014-02-04, This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. "Security Services for the Registration Data Access Protocol", Scott Hollenbeck, Ning Kong, 2014-02-10, The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. "HTTP usage in the Registration Data Access Protocol (RDAP)", Andrew Newton, Byron Ellacott, Ning Kong, 2014-02-04, This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). "Redirection Service for Registration Data Access Protocol", Carlos Martinez, Linlin Zhou, Gerardo Rada, 2014-02-14, The traditional WHOIS protocol has several important shortcomings, and over the past few years several approaches to a better Registration Data Access Protocol (RDAP) have been discussed and proposed. It is worth noting that the term WHOIS is sometimes used interchangeably to mean either (a) the registration data itself or (b) the protocol used to access registration data Among these shortcomings, different registries operate different WHOIS services. For users this means that several WHOIS queries to different registries may be necessary in order to obtain data for a given resource. This document describes a redirection service for RDAP queries. This service allows clients to query a single RDAP service and expect either an authoritative answer or a redirection hint pointing to another, possibly authoritative, RDAP server. The solution implemented proposed here applies to Regional Internet Registries(RIRs) and Domain Name Registries(DNRs). "Registration Data Access Protocol Object Inventory Analysis", Linlin Zhou, Ning Kong, Sean Shen, Arturo Servin, Steve Sheng, 2014-01-21, WHOIS output objects from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) were collected and analyzed. This document describes the statistical analysis process and result of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses. "Finding the Authoritative Registration Data (RDAP) Service", Marc Blanchet, 2014-06-23, This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. Web PKI OPS (wpkops) -------------------- "Trust models of the Web PKI", Inigo Barreira, Bruce Morton, 2014-05-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. "Web PKI Operations: Revocation and Status", Phillip Hallam-Baker, David Chadwick, 2014-05-13, This document describes the certificate status mechanisms supported in the Web PKI Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, Matthew Miller, 2014-06-21, This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream. Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in multi-tenanted environments. "Extensible Messaging and Presence Protocol (XMPP): Address Format", Peter Saint-Andre, 2014-03-31, 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. "An XMPP Sub-protocol for WebSocket", Lance Stout, Jack Moffitt, Eric Cestari, 2014-06-06, This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. "PKIX over Secure HTTP (POSH)", Matthew Miller, Peter Saint-Andre, 2014-06-19, Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments, since certification authorities will not issue certificates for hosted domains to hosting services, hosted domains do not want hosting services to hold their private keys, and hosting services wish to avoid liability for holding those keys. As a result, domains hosted in multi-tenanted environments often deploy non-HTTP applications such as email and instant messaging 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. The first method enables the TLS client associated with a user agent or peer application server to obtain the end-entity certificate of a hosted domain over secure HTTP as an alternative to standard PKIX techniques. The second method enables a hosted domain to securely delegate a non-HTTP application to a hosting service using redirects provided by HTTPS itself or by a pointer in a file served over HTTPS at the hosted domain. While this approach was developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association prooftype, it can be applied to any non-HTTP application protocol. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) --------------------------------------------------------------------- "RTCP XR Report Block for Concealment metrics Reporting on Audio Applications", Alan Clark, Glen Zorn, Claire Bi, Wenson Wu, 2014-04-10, This document defines two RTCP XR Report Blocks that allows the reporting of concealment metrics for audio applications of RTP. "RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics", Rachel Huang, Varun Singh, 2014-06-24, This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss count metrics for a range of RTP applications. "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics reporting", Jiangang Tong, Claire Bi, Roni Even, Qin Wu, Rachel Huang, 2014-06-05, An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/Multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR Block are related to Program specific information carried in MPEG TS.