RFC Abstracts
RFC7844 - Anonymity Profiles for DHCP Clients
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.
RFC7843 - Port Control Protocol (PCP) Third-Party ID Option
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.
RFC7842 - Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool
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.
RFC7841 - RFC Streams, Headers, and Boilerplates
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.
RFC7840 - 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.
RFC7839 - Access-Network-Identifier Option in DHCP
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.
RFC7838 - HTTP Alternative Services
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.
RFC7837 - IPv6 Destination Option for Congestion Exposure (ConEx)
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.
RFC7836 - Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST 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.
RFC7835 - Locator/ID Separation Protocol (LISP) Threat Analysis
This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).
RFC7834 - Locator/ID Separation Protocol (LISP) Impact
The Locator/ID Separation Protocol (LISP) aims to improve the Internet 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 of LISP can have on both the routing infrastructure and the end user.
RFC7833 - A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)
This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging 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. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a 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.
RFC7832 - Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases
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 Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.
RFC7831 - Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
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.
RFC7830 - The EDNS(0) Padding Option
This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.
RFC7829 - SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
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.
RFC7828 - The edns-tcp-keepalive EDNS0 Option
DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
RFC7827 - The Role of the IRTF Chair
This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.
RFC7826 - Real-Time Streaming Protocol Version 2.0
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RFC7825 - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
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 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.
RFC7824 - Privacy Considerations for DHCPv6
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.
RFC7823 - Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label 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.
RFC7822 - 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 RFC 5905, 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).
RFC7821 - UDP Checksum Complement in the Network Time Protocol (NTP)
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 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.
RFC7820 - UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
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 time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.
RFC7819 - Privacy Considerations for DHCP
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.
RFC7818 - URN Namespace for MEF Documents
This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF 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 the MEF Assigned Names and Numbers (MANN) registry.
RFC7817 - 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, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.
RFC7816 - 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.
RFC7815 - Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations 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.
RFC7814 - Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution
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.
RFC7813 - IS-IS Path Control and Reservation
IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.
RFC7812 - An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
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.
RFC7811 - An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
This document supports the solution put forth in "An Architecture for IP/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 necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.
RFC7810 - IS-IS Traffic Engineering (TE) Metric Extensions
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.
RFC7809 - Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.
RFC7808 - Time Zone Data Distribution Service
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.
RFC7807 - Problem Details for HTTP APIs
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.
RFC7806 - On Queuing, Marking, and Dropping
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.
RFC7805 - Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status
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 reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.
RFC7804 - Salted Challenge Response HTTP Authentication Mechanism
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.
RFC7803 - 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 Standards Track RFCs.
RFC7802 - 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 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.
RFC7801 - GOST R 34.12-2015: Block Cipher "Kuznyechik"
This document is intended to be a source of information about the Russian 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 (called GOST algorithms).
RFC7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
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.
RFC7799 - Active and Passive Metrics and Methods (with Hybrid Types In-Between)
This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.
RFC7798 - RTP Payload Format for High Efficiency Video Coding (HEVC)
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.
RFC7797 - JSON Web Signature (JWS) Unencoded Payload Option
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
RFC7796 - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (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 specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.
RFC7795 - Pseudowire Redundancy on the Switching Provider Edge (S-PE)
This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused. This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.
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.
RFC7843 - Port Control Protocol (PCP) Third-Party ID Option
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.
RFC7842 - Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool
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.
RFC7841 - RFC Streams, Headers, and Boilerplates
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.
RFC7840 - 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.
RFC7839 - Access-Network-Identifier Option in DHCP
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.
RFC7838 - HTTP Alternative Services
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.
RFC7837 - IPv6 Destination Option for Congestion Exposure (ConEx)
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.
RFC7836 - Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST 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.
RFC7835 - Locator/ID Separation Protocol (LISP) Threat Analysis
This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).
RFC7834 - Locator/ID Separation Protocol (LISP) Impact
The Locator/ID Separation Protocol (LISP) aims to improve the Internet 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 of LISP can have on both the routing infrastructure and the end user.
RFC7833 - A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)
This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging 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. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a 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.
RFC7832 - Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases
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 Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.
RFC7831 - Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
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.
RFC7830 - The EDNS(0) Padding Option
This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.
RFC7829 - SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
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.
RFC7828 - The edns-tcp-keepalive EDNS0 Option
DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
RFC7827 - The Role of the IRTF Chair
This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.
RFC7826 - Real-Time Streaming Protocol Version 2.0
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RFC7825 - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
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 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.
RFC7824 - Privacy Considerations for DHCPv6
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.
RFC7823 - Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label 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.
RFC7822 - 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 RFC 5905, 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).
RFC7821 - UDP Checksum Complement in the Network Time Protocol (NTP)
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 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.
RFC7820 - UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
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 time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.
RFC7819 - Privacy Considerations for DHCP
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.
RFC7818 - URN Namespace for MEF Documents
This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF 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 the MEF Assigned Names and Numbers (MANN) registry.
RFC7817 - 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, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.
RFC7816 - 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.
RFC7815 - Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations 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.
RFC7814 - Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution
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.
RFC7813 - IS-IS Path Control and Reservation
IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.
RFC7812 - An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
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.
RFC7811 - An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)
This document supports the solution put forth in "An Architecture for IP/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 necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.
RFC7810 - IS-IS Traffic Engineering (TE) Metric Extensions
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.
RFC7809 - Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.
RFC7808 - Time Zone Data Distribution Service
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.
RFC7807 - Problem Details for HTTP APIs
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.
RFC7806 - On Queuing, Marking, and Dropping
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.
RFC7805 - Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status
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 reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.
RFC7804 - Salted Challenge Response HTTP Authentication Mechanism
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.
RFC7803 - 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 Standards Track RFCs.
RFC7802 - 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 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.
RFC7801 - GOST R 34.12-2015: Block Cipher "Kuznyechik"
This document is intended to be a source of information about the Russian 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 (called GOST algorithms).
RFC7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
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.
RFC7799 - Active and Passive Metrics and Methods (with Hybrid Types In-Between)
This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.
RFC7798 - RTP Payload Format for High Efficiency Video Coding (HEVC)
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.
RFC7797 - JSON Web Signature (JWS) Unencoded Payload Option
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
RFC7796 - Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (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 specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.
RFC7795 - Pseudowire Redundancy on the Switching Provider Edge (S-PE)
This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused. This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.