| |
| RFC 7800 | Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) |
| |
| Authors: | M. Jones, J. Bradley, H. Tschofenig. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7800 |
|
This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. |
|
| |
| RFC 7801 | GOST R 34.12-2015: Block Cipher "Kuznyechik" |
| |
| Authors: | V. Dolmatov, Ed.. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7801 |
|
This document is intended to be a source of information about theRussian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (calledGOST algorithms). |
|
| |
| RFC 7802 | A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism |
| |
|
|
This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos 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 asHistoric. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations. |
|
| |
| RFC 7803 | Changing the Registration Policy for the NETCONF Capability URNs Registry |
| |
|
|
The registration policy for the "Network Configuration Protocol(NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to StandardsTrack RFCs. |
|
| |
| RFC 7804 | Salted Challenge Response HTTP Authentication Mechanism |
| |
| Authors: | A. Melnikov. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7804 |
|
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response AuthenticationMechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport LayerSecurity (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms. |
|
| |
| RFC 7805 | Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status |
| |
| Authors: | A. Zimmermann, W. Eddy, L. Eggert. |
| Date: | April 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 0675, RFC 0721, RFC 0761, RFC 0813, RFC 0816, RFC 0879, RFC 0896, RFC 1078, RFC 6013 |
| Updates: | RFC 7414 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7805 |
|
This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816,879, 896, 1078, and 6013. Additionally, this document reclassifiesRFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status. |
|
| |
| RFC 7806 | On Queuing, Marking, and Dropping |
| |
| Authors: | F. Baker, R. Pan. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7806 |
|
This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior. |
|
| |
| RFC 7807 | Problem Details for HTTP APIs |
| |
| Authors: | M. Nottingham, E. Wilde. |
| Date: | March 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9457 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7807 |
|
This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. |
|
| |
| RFC 7808 | Time Zone Data Distribution Service |
| |
| Authors: | M. Douglass, C. Daboo. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7808 |
|
This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems. |
|
| |
| RFC 7809 | Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference |
| |
|
|
This document defines an update to the Calendaring Extensions toWebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data. |
|
| |
| RFC 7810 | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. |
| Date: | May 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8570 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7810 |
|
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 EngineeringExtensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS 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. |
|
| |
| RFC 7811 | An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) |
| |
| Authors: | G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7811 |
|
This document supports the solution put forth in "An Architecture forIP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"(RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessaryMaximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR. |
|
| |
| RFC 7812 | An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) |
| |
| Authors: | A. Atlas, C. Bowers, G. Enyedi. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7812 |
|
This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. |
|
| |
| RFC 7813 | IS-IS Path Control and Reservation |
| |
| Authors: | J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7813 |
|
IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest PathBridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. |
|
| |
| RFC 7814 | Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution |
| |
| Authors: | X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7814 |
|
This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers. |
|
| |
| RFC 7815 | Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation |
| |
| Authors: | T. Kivinen. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7815 |
|
This document describes a minimal initiator version of the InternetKey Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.
This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description. |
|
| |
| RFC 7816 | DNS Query Name Minimisation to Improve Privacy |
| |
|
|
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. |
|
| |
| RFC 7817 | Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols |
| |
|
|
This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, andManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLSCommand) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804. |
|
| |
| RFC 7818 | URN Namespace for MEF Documents |
| |
| Authors: | M. Jethanandani. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7818 |
|
This document describes the Namespace Identifier (NID) "mef" forUniform Resource Names (URNs) used to identify resources published byMEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of theMEF Assigned Names and Numbers (MANN) registry. |
|
| |
| RFC 7819 | Privacy Considerations for DHCP |
| |
| Authors: | S. Jiang, S. Krishnan, T. Mrugalski. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7819 |
|
DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. |
|
| |
| RFC 7820 | UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | T. Mizrahi. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7820 |
|
The One-Way Active Measurement Protocol (OWAMP) and the Two-WayActive 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 time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDPChecksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as aChecksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDPChecksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. |
|
| |
| RFC 7821 | UDP Checksum Complement in the Network Time Protocol (NTP) |
| |
| Authors: | T. Mizrahi. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7821 |
|
The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate 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 Complement, allowing timestamping engines to reflect the checksum modification in the last2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations. |
|
| |
| RFC 7822 | Network Time Protocol Version 4 (NTPv4) Extension Fields |
| |
|
|
The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes(MACs). |
|
| |
| RFC 7823 | Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions |
| |
| Authors: | A. Atlas, J. Drake, S. Giacalone, S. Previdi. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7823 |
|
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TELabel Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. |
|
| |
| RFC 7824 | Privacy Considerations for DHCPv6 |
| |
| Authors: | S. Krishnan, T. Mrugalski, S. Jiang. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7824 |
|
DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users.It is intended to be an analysis of the present situation and does not propose any solutions. |
|
| |
| RFC 7825 | A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) |
| |
| Authors: | J. Goldberg, M. Westerlund, T. Zeng. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7825 |
|
This document defines a solution for Network Address Translation(NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures. |
|
| |
| RFC 7826 | Real-Time Streaming Protocol Version 2.0 |
| |
| Authors: | H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.. |
| Date: | December 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 2326 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7826 |
|
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RTSP is an application-layer protocol for the 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). |
|
| |
| RFC 7827 | The Role of the IRTF Chair |
| |
| Authors: | L. Eggert. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7827 |
|
This document briefly describes the role of the Chair of the InternetResearch Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have. |
|
| |
| RFC 7828 | The edns-tcp-keepalive EDNS0 Option |
| |
| Authors: | P. Wouters, J. Abley, S. Dickinson, R. Bellis. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7828 |
|
DNS messages between clients and servers may be received over eitherUDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally,UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. |
|
| |
| RFC 7829 | SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol |
| |
| Authors: | Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7829 |
|
The Stream Control Transmission Protocol (SCTP) supports multihoming.However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed(SCTP-PF) destination state in SCTP Path Management.
This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.
Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.
The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver. |
|
| |
| RFC 7830 | The EDNS(0) Padding Option |
| |
| Authors: | A. Mayrhofer. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7830 |
|
This document specifies the EDNS(0) "Padding" option, which allowsDNS clients and servers to pad request and response messages by a variable number of octets. |
|
| |
| RFC 7831 | Application Bridging for Federated Access Beyond Web (ABFAB) Architecture |
| |
| Authors: | J. Howlett, S. Hartman, H. Tschofenig, J. Schaad. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7831 |
|
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 AuthenticationDial-In User Service (RADIUS), the Generic Security ServiceApplication Program Interface (GSS-API), the ExtensibleAuthentication Protocol (EAP), and the Security Assertion MarkupLanguage (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, RelyingParties, and federations. |
|
| |
| RFC 7832 | Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases |
| |
| Authors: | R. Smith, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7832 |
|
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 memo 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 ApplicationBridging for Federated Access Beyond web (ABFAB) architecture and specifications. |
|
| |
| RFC 7833 | A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) |
| |
| Authors: | J. Howlett, S. Hartman, A. Perez-Mendez, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7833 |
|
This document describes the use of the Security Assertion MarkupLanguage (SAML) with RADIUS in the context of the ApplicationBridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. TheRADIUS 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 assertionQuery/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format.Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting(AAA) scenario, such as network access control. |
|
| |
| RFC 7834 | Locator/ID Separation Protocol (LISP) Impact |
| |
| Authors: | D. Saucez, L. Iannone, A. Cabellos, F. Coras. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7834 |
|
The Locator/ID Separation Protocol (LISP) aims to improve theInternet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment ofLISP can have on both the routing infrastructure and the end user. |
|
| |
| RFC 7835 | Locator/ID Separation Protocol (LISP) Threat Analysis |
| |
| Authors: | D. Saucez, L. Iannone, O. Bonaventure. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7835 |
|
This document provides a threat analysis of the Locator/ID SeparationProtocol (LISP). |
|
| |
| RFC 7836 | Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012 |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7836 |
|
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standardsGOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions. |
|
| |
| RFC 7837 | IPv6 Destination Option for Congestion Exposure (ConEx) |
| |
| Authors: | S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7837 |
|
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. |
|
| |
| RFC 7838 | HTTP Alternative Services |
| |
| Authors: | M. Nottingham, P. McManus, J. Reschke. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7838 |
|
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. |
|
| |
| RFC 7839 | Access-Network-Identifier Option in DHCP |
| |
| Authors: | S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7839 |
|
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. |
|
| |
| RFC 7840 | A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol |
| |
|
|
For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations. |
|
| |
| RFC 7841 | RFC Streams, Headers, and Boilerplates |
| |
| Authors: | J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 5741 |
| Updated by: | RFC 9280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7841 |
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats. |
|
| |
| RFC 7842 | Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool |
| |
| Authors: | R. Sparks. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7842 |
|
The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use. |
|
| |
| RFC 7843 | Port Control Protocol (PCP) Third-Party ID Option |
| |
| Authors: | A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7843 |
|
This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.
The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in theTHIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device. |
|
| |
| RFC 7844 | Anonymity Profiles for DHCP Clients |
| |
| Authors: | C. Huitema, T. Mrugalski, S. Krishnan. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7844 |
|
Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information. |
|
| |
| RFC 7845 | Ogg Encapsulation for the Opus Audio Codec |
| |
|
|
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. |
|
| |
| RFC 7846 | Peer-to-Peer Streaming Tracker Protocol (PPSTP) |
| |
| Authors: | R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7846 |
|
This document specifies the base Peer-to-Peer Streaming TrackerProtocol (PPSTP) version 1, 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; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content- streaming overlay networks to support near real-time delivery of structured media content (audio, video, and 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. |
|
| |
| RFC 7847 | Logical-Interface Support for IP Hosts with Multi-Access Support |
| |
| Authors: | T. Melia, Ed., S. Gundavelli, Ed.. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7847 |
|
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.Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support. This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features. |
|
| |
| RFC 7848 | Mark and Signed Mark Objects Mapping |
| |
| Authors: | G. Lozano. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7848 |
|
Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).
One of those special modes of operation is the Sunrise Period. TheSunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.
This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty. |
|
| |
| RFC 7849 | An IPv6 Profile for 3GPP Mobile Devices |
| |
| Authors: | D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7849 |
|
This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third GenerationPartnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation PartnershipProject (3GPP) Cellular Hosts" (RFC 7066).
Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope. |
|
| |
| RFC 7850 | Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles |
| |
| Authors: | S. Nandakumar. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7850 |
|
The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following newSDP transport protocol identifiers for transporting RTP Media overTCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF','TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and'TCP/TLS/RTP/AVPF'. |
|
| |
| RFC 7851 | Peer-to-Peer (P2P) Overlay Diagnostics |
| |
| Authors: | H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7851 |
|
This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation AndDiscovery (RELOAD) 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. |
|
| |
| RFC 7852 | Additional Data Related to an Emergency Call |
| |
| Authors: | R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom. |
| Date: | July 2016 |
| Formats: | txt html json |
| Updates: | RFC 6443, RFC 6881 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7852 |
|
When an emergency call is sent to a Public Safety Answering Point(PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency.This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.
The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. |
|
| |
| RFC 7853 | A URN Namespace for Globus |
| |
| Authors: | S. Martin, S. Tuecke, B. McCollam, M. Lidman. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7853 |
|
This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources. |
|
| |
| RFC 7854 | BGP Monitoring Protocol (BMP) |
| |
|
|
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.BMP is not suitable for use as a routing protocol. |
|
| |
| RFC 7855 | Source Packet Routing in Networking (SPRING) Problem Statement and Requirements |
| |
| Authors: | S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7855 |
|
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"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).
This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing inNetworking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document. |
|
| |
| RFC 7856 | Softwire Mesh Management Information Base (MIB) |
| |
| Authors: | Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7856 |
|
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 a softwire mesh. |
|
| |
| RFC 7857 | Updates to Network Address Translation (NAT) Behavioral Requirements |
| |
|
|
This document clarifies and updates several requirements of RFCs4787, 5382, and 5508 based on operational and development experience.The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).
This document updates RFCs 4787, 5382, and 5508. |
|
| |
| RFC 7858 | Specification for DNS over Transport Layer Security (TLS) |
| |
| Authors: | Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. |
| Date: | May 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8310 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7858 |
|
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.
This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. |
|
| |
| RFC 7859 | Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols |
| |
| Authors: | C. Dearlove. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7859 |
|
This document extends RFC 7182, 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-BasedSignature (IBS), defined according to the Elliptic Curve-BasedCertificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507. |
|
| |
| RFC 7860 | HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 |
| |
| Authors: | J. Merkle, Ed., M. Lochter. |
| Date: | April 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 7630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7860 |
|
This document specifies several authentication protocols based on theSHA-2 hash functions for the User-based Security Model (USM) forSNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIBMODULE-IDENTITY value was incorrectly specified. |
|
| |
| RFC 7861 | Remote Procedure Call (RPC) Security Version 3 |
| |
| Authors: | A. Adamson, N. Williams. |
| Date: | November 2016 |
| Formats: | txt json html |
| Updates: | RFC 5403 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7861 |
|
This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updatesRFC 5403. |
|
| |
| RFC 7862 | Network File System (NFS) Version 4 Minor Version 2 Protocol |
| |
|
|
This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O)Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. |
|
| |
| RFC 7863 | Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description |
| |
| Authors: | T. Haynes. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7863 |
|
This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2. |
|
| |
| RFC 7864 | Proxy Mobile IPv6 Extensions to Support Flow Mobility |
| |
|
|
Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.
This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. |
|
| |
| RFC 7865 | Session Initiation Protocol (SIP) Recording Metadata |
| |
| Authors: | R. Ravindranath, P. Ravindran, P. Kyzivat. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7865 |
|
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.The 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 the Session Recording Server (SRS) and the recording metadata format. |
|
| |
| RFC 7866 | Session Recording Protocol |
| |
| Authors: | L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7866 |
|
This document specifies the use of the Session Initiation Protocol(SIP), the Session Description Protocol (SDP), and the Real-timeTransport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The SessionRecording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session RecordingClient (SRC), which is on the path of the CS, and a Session RecordingServer (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. |
|
| |
| RFC 7867 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications |
| |
| Authors: | R. Huang. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7867 |
|
This document defines a new RTP Control Protocol (RTCP) ExtendedReport (XR) block that allows the reporting of loss concealment metrics for video applications of RTP. |
|
| |
| RFC 7868 | Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) |
| |
| Authors: | D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7868 |
|
This document describes the protocol design and architecture forEnhanced 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 as referenced in "Loop-Free Routing Using Diffusing Computations"(Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International. |
|
| |
| RFC 7869 | The "vnc" URI Scheme |
| |
| Authors: | D. Warden, I. Iordanov. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7869 |
|
Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier(URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts. |
|
| |
| RFC 7870 | Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) |
| |
| Authors: | Y. Fu, S. Jiang, J. Dong, Y. Chen. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7870 |
|
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 Address FamilyTransition Routers (AFTRs) of Dual-Stack Lite (DS-Lite). |
|
| |
| RFC 7871 | Client Subnet in DNS Queries |
| |
| Authors: | C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7871 |
|
This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. |
|
| |
| RFC 7872 | Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World |
| |
| Authors: | F. Gont, J. Linkova, T. Chown, W. Liu. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7872 |
|
This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet(as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. |
|
| |
| RFC 7873 | Domain Name System (DNS) Cookies |
| |
| Authors: | D. Eastlake 3rd, M. Andrews. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9018 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7873 |
|
DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNSCookies are tolerant of NAT, NAT-PT (Network Address Translation -Protocol Translation), and anycast and can be incrementally deployed.(Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally trackInternet users.) |
|
| |
| RFC 7874 | WebRTC Audio Codec and Processing Requirements |
| |
| Authors: | JM. Valin, C. Bran. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7874 |
|
This document outlines the audio codec and processing requirements for WebRTC endpoints. |
|
| |
| RFC 7875 | Additional WebRTC Audio Codecs for Interoperability |
| |
| Authors: | S. Proust, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7875 |
|
To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing 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 endpoints to address the use cases most relevant to interoperability. |
|
| |
| RFC 7876 | UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks |
| |
| Authors: | S. Bryant, S. Sivabalan, S. Soni. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7876 |
|
RFC 6374 defines a protocol for Packet Loss and Delay Measurement forMPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path. |
|
| |
| RFC 7877 | Session Peering Provisioning Framework (SPPF) |
| |
| Authors: | K. Cartwright, V. Bhatia, S. Ali, D. Schwartz. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7877 |
|
This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) intoSession Data Registries and SIP Service Provider (SSP) data stores.The framework is called the "Session Peering Provisioning Framework"(SPPF). The provisioned data is typically used by network elements for session establishment. |
|
| |
| RFC 7878 | Session Peering Provisioning (SPP) Protocol over SOAP |
| |
| Authors: | K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7878 |
|
The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session EstablishmentData (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol.Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF- based protocol. |
|
| |
| RFC 7879 | DTLS-SRTP Handling in SIP Back-to-Back User Agents |
| |
| Authors: | R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7879 |
|
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-timeTransport (SRTP) security context is set up with the DatagramTransport Layer Security (DTLS) protocol. |
|
| |
| RFC 7880 | Seamless Bidirectional Forwarding Detection (S-BFD) |
| |
| Authors: | C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7880 |
|
This document defines Seamless Bidirectional Forwarding Detection(S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
This document updates RFC 5880. |
|
| |
| RFC 7881 | Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS |
| |
| Authors: | C. Pignataro, D. Ward, N. Akiya. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7881 |
|
This document defines procedures for using Seamless BidirectionalForwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments. |
|
| |
| RFC 7882 | Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases |
| |
| Authors: | S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7882 |
|
This document describes various use cases for Seamless BidirectionalForwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.
These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits ofS-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. |
|
| |
| RFC 7883 | Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS |
| |
| Authors: | L. Ginsberg, N. Akiya, M. Chen. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7883 |
|
This document defines a means of advertising one or more SeamlessBidirectional Forwarding Detection (S-BFD) Discriminators using theIS-IS Router CAPABILITY TLV. |
|
| |
| RFC 7884 | OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators |
| |
| Authors: | C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7884 |
|
This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional ForwardingDetection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 andOSPFv3. |
|
| |
| RFC 7885 | Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) |
| |
| Authors: | V. Govindan, C. Pignataro. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 5885 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7885 |
|
This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual CircuitConnectivity Verification (VCCV).
This document updates RFC 5885 by extending the CV Type values and the capability selection. |
|
| |
| RFC 7886 | Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | V. Govindan, C. Pignataro. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7886 |
|
This document defines a new Attribute-Value Pair (AVP) that allowsL2TP Control Connection Endpoints (LCCEs) to advertise one or moreSeamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3). |
|
| |
| RFC 7887 | Hierarchical Join/Prune Attributes |
| |
| Authors: | S. Venaas, J. Arango, I. Kouvelas. |
| Date: | June 2016 |
| Formats: | txt html json |
| Updates: | RFC 5384 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7887 |
|
This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIMJoin/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there. |
|
| |
| RFC 7888 | IMAP4 Non-synchronizing Literals |
| |
|
|
The Internet Message Access Protocol (RFC 3501) contains the"literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.LITERAL+ allows the alternate form of literals in all IMAP commands.LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.
This document obsoletes RFC 2088. |
|
| |
| RFC 7889 | The IMAP APPENDLIMIT Extension |
| |
| Authors: | J. SrimushnamBoovaraghamoorthy, N. Bisht. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7889 |
|
This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. |
|
| |
| RFC 7890 | Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) |
| |
| Authors: | D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7890 |
|
This document defines concepts and terminology for using the SessionInitiation 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, the REsource LOcation And Discovery (RELOAD) protocol, and theSIP usage document defined by the working group. |
|
| |
| RFC 7891 | Explicit Reverse Path Forwarding (RPF) Vector |
| |
| Authors: | J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7891 |
|
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 Rendezvous Point 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, thus bypassing the unicast route lookup. |
|
| |
| RFC 7892 | IANA Allocation Procedures for the GMPLS OTN Signal Type Registry |
| |
| Authors: | Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updates: | RFC 7139 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7892 |
|
IANA defined the "OTN Signal Type" subregistry of the "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required. |
|
| |
| RFC 7893 | Pseudowire Congestion Considerations |
| |
| Authors: | Y(J) Stein, D. Black, B. Briscoe. |
| Date: | June 2016 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7893 |
|
Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound.Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required. |
|
| |
| RFC 7894 | Alternative Challenge Password Attributes for Enrollment over Secure Transport |
| |
| Authors: | M. Pritikin, C. Wallace. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7894 |
|
This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS#9: Selected Object Classes and Attribute Types Version 2.0" (RFC2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity. |
|
| |
| RFC 7895 | YANG Module Library |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | June 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7895 |
|
This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. |
|
| |
| RFC 7896 | Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.
This document updates RFC 5440 regarding the IRO specification. |
|
| |
| RFC 7897 | Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Dhody, U. Palle, R. Casellas. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7897 |
|
The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized 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 InteriorGateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a 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 PathComputation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers. |
|
| |
| RFC 7898 | Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) |
| |
| Authors: | D. Dhody, U. Palle, V. Kondreddy, R. Casellas. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7898 |
|
The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.
This document specifies new subobjects to include or excludeAutonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup. |
|
| |
| RFC 7899 | Multicast VPN State Damping |
| |
| Authors: | T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas. |
| Date: | June 2016 |
| Formats: | txt json html |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7899 |
|
This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast. |
|
