RFC Abstracts
RFC8854 - WebRTC Forward Error Correction Requirements
This document provides information and requirements for the use of Forward Error Correction (FEC) by WebRTC implementations.
RFC8853 - Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.
RFC8852 - RTP Stream Identifier Source Description (SDES)
This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream.
RFC8851 - RTP Payload Format Restrictions
In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol (SDP). This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
RFC8850 - Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel
This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities.
RFC8849 - Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams for Telepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in the Session Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID).
RFC8848 - Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
This document is about Controlling Multiple Streams for Telepresence (CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the Session Description Protocol (SDP), to produce a telepresence call.
RFC8847 - Protocol for Controlling Multiple Streams for Telepresence (CLUE)
The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE Working Group. A companion document, RFC 8848, delves into CLUE signaling details as well as the SIP / Session Description Protocol (SDP) session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control Transmission Protocol".) Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.
RFC8846 - An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.
RFC8845 - Framework for Telepresence Multi-Streams
This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.
RFC8844 - Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)
This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.
RFC8843 - Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.
RFC8842 - Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.
RFC8841 - Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport
The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.
RFC8840 - A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
RFC8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents.
RFC8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.
RFC8837 - Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic.
RFC8836 - Congestion Control Requirements for Interactive Real-Time Media
Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
RFC8835 - Transports for WebRTC
This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.
RFC8834 - Media Transport and Use of RTP in WebRTC
The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported.
RFC8833 - Application-Layer Protocol Negotiation (ALPN) for WebRTC
This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC). The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.
RFC8832 - WebRTC Data Channel Establishment Protocol
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.
RFC8831 - WebRTC Data Channels
The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer.
RFC8830 - WebRTC MediaStream Identification in the Session Description Protocol
This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.
RFC8829 - JavaScript Session Establishment Protocol (JSEP)
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.
RFC8828 - WebRTC IP Address Handling Requirements
This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations.
RFC8827 - WebRTC Security Architecture
This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
RFC8826 - Security Considerations for WebRTC
WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.
RFC8825 - Overview: Real-Time Protocols for Browser-Based Applications
This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
RFC8824 - Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.
RFC8823 - Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
RFC8822 - 5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).
RFC8821 - PCE-Based Traffic Engineering (TE) in Native IP Networks
This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP).
RFC8820 - URI Design and Ownership
Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.
RFC8819 - YANG Module Tags
This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading, and writing modules tags is provided. Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407.
RFC8818 - Distributed Mobility Anchoring
This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.
RFC8817 - RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec
This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation Linear Prediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.
RFC8816 - Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases
The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.
RFC8815 - Deprecating Any-Source Multicast (ASM) for Interdomain Multicast
This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).
RFC8814 - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.
RFC8813 - Clarifications for Elliptic Curve Cryptography Subject Public Key Information
This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.
RFC8812 - CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms
The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.
RFC8811 - DDoS Open Threat Signaling (DOTS) Architecture
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.
RFC8810 - Revision to Capability Codes Registration Procedures
This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".
RFC8809 - Registries for Web Authentication (WebAuthn)
This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers.
RFC8808 - A YANG Data Model for Factory Default Settings
This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.
RFC8807 - Login Security Extension for the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.
RFC8806 - Running a Root Server Local to a Resolver
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.
RFC8805 - A Format for Self-Published IP Geolocation Feeds
This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.
This document provides information and requirements for the use of Forward Error Correction (FEC) by WebRTC implementations.
RFC8853 - Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.
RFC8852 - RTP Stream Identifier Source Description (SDES)
This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream.
RFC8851 - RTP Payload Format Restrictions
In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol (SDP). This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
RFC8850 - Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel
This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities.
RFC8849 - Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams for Telepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in the Session Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID).
RFC8848 - Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
This document is about Controlling Multiple Streams for Telepresence (CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the Session Description Protocol (SDP), to produce a telepresence call.
RFC8847 - Protocol for Controlling Multiple Streams for Telepresence (CLUE)
The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE Working Group. A companion document, RFC 8848, delves into CLUE signaling details as well as the SIP / Session Description Protocol (SDP) session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control Transmission Protocol".) Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.
RFC8846 - An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model
This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.
RFC8845 - Framework for Telepresence Multi-Streams
This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.
RFC8844 - Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)
This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.
RFC8843 - Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.
RFC8842 - Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.
RFC8841 - Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport
The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.
RFC8840 - A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
RFC8839 - Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents.
RFC8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.
RFC8837 - Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic.
RFC8836 - Congestion Control Requirements for Interactive Real-Time Media
Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
RFC8835 - Transports for WebRTC
This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.
RFC8834 - Media Transport and Use of RTP in WebRTC
The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported.
RFC8833 - Application-Layer Protocol Negotiation (ALPN) for WebRTC
This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC). The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.
RFC8832 - WebRTC Data Channel Establishment Protocol
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.
RFC8831 - WebRTC Data Channels
The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer.
RFC8830 - WebRTC MediaStream Identification in the Session Description Protocol
This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.
RFC8829 - JavaScript Session Establishment Protocol (JSEP)
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.
RFC8828 - WebRTC IP Address Handling Requirements
This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations.
RFC8827 - WebRTC Security Architecture
This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
RFC8826 - Security Considerations for WebRTC
WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.
RFC8825 - Overview: Real-Time Protocols for Browser-Based Applications
This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
RFC8824 - Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.
RFC8823 - Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
RFC8822 - 5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).
RFC8821 - PCE-Based Traffic Engineering (TE) in Native IP Networks
This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP).
RFC8820 - URI Design and Ownership
Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.
RFC8819 - YANG Module Tags
This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading, and writing modules tags is provided. Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407.
RFC8818 - Distributed Mobility Anchoring
This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.
RFC8817 - RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec
This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation Linear Prediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.
RFC8816 - Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases
The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.
RFC8815 - Deprecating Any-Source Multicast (ASM) for Interdomain Multicast
This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).
RFC8814 - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.
RFC8813 - Clarifications for Elliptic Curve Cryptography Subject Public Key Information
This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.
RFC8812 - CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms
The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.
RFC8811 - DDoS Open Threat Signaling (DOTS) Architecture
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.
RFC8810 - Revision to Capability Codes Registration Procedures
This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".
RFC8809 - Registries for Web Authentication (WebAuthn)
This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers.
RFC8808 - A YANG Data Model for Factory Default Settings
This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.
RFC8807 - Login Security Extension for the Extensible Provisioning Protocol (EPP)
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.
RFC8806 - Running a Root Server Local to a Resolver
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.
RFC8805 - A Format for Self-Published IP Geolocation Feeds
This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.