| |
| RFC 8800 | Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling |
| |
| Authors: | S. Litkowski, S. Sivabalan, C. Barth, M. Negi. |
| Date: | July 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8800 |
|
This document introduces a simple mechanism to associate a group ofLabel Switched Paths (LSPs) via an extension to the Path ComputationElement Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PathComputation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that theLSPs in the same group need to be disjoint from each other. |
|
| |
| RFC 8801 | Discovering Provisioning Domain Names and Data |
| |
| Authors: | P. Pfister, É. Vyncke, T. Pauly, D. Schinazi, W. Shao. |
| Date: | July 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8801 |
|
Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.
This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate betweenPvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS. |
|
| |
| RFC 8802 | The Quality for Service (Q4S) Protocol |
| |
| Authors: | J.J. Aranda, M. Cortes, J. Salvachúa, M. Narganes, I. Martínez-Sarriegui. |
| Date: | July 2020 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8802 |
|
This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on theHyperText Transfer Protocol (HTTP) and the Session DescriptionProtocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.
Implementation details on the actions to be triggered upon reception/ detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).
This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus. |
|
| |
| RFC 8803 | 0-RTT TCP Convert Protocol |
| |
| Authors: | O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans. |
| Date: | July 2020 |
| Formats: | txt pdf xml html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8803 |
|
This document specifies an application proxy, called TransportConverter, to assist the deployment of TCP extensions such asMultipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).
This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).
This specification assumes an explicit model, where the TransportConverter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the ConvertProtocol applies for Multipath TCP. |
|
| |
| RFC 8804 | Content Delivery Network Interconnection (CDNI) Request Routing Extensions |
| |
| Authors: | O. Finkelman, S. Mishra. |
| Date: | September 2020 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8804 |
|
Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint &Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. |
|
| |
| RFC 8805 | A Format for Self-Published IP Geolocation Feeds |
| |
| Authors: | E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari. |
| Date: | August 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8805 |
|
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.
Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. |
|
| |
| RFC 8806 | 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.
This document obsoletes RFC 7706. |
|
| |
| RFC 8807 | 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 XMLSchema 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. |
|
| |
| RFC 8808 | A YANG Data Model for Factory Default Settings |
| |
| Authors: | Q. Wu, B. Lengyel, Y. Niu. |
| Date: | August 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8808 |
|
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.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 8809 | Registries for Web Authentication (WebAuthn) |
| |
| Authors: | J. Hodges, G. Mandyam, M. Jones. |
| Date: | August 2020 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8809 |
|
This specification defines IANA registries for W3C Web Authentication(WebAuthn) attestation statement format identifiers and extension identifiers. |
|
| |
| RFC 8810 | 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". |
|
| |
| RFC 8811 | DDoS Open Threat Signaling (DOTS) Architecture |
| |
| Authors: | A. Mortensen, Ed., T. Reddy.K, Ed., F. Andreasen, N. Teague, R. Compton. |
| Date: | August 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8811 |
|
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open ThreatSignaling (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. |
|
| |
| RFC 8812 | 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 FIDOAlliance 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. |
|
| |
| RFC 8813 | 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. |
|
| |
| RFC 8814 | Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State |
| |
| Authors: | J. Tantsura, U. Chunduri, K. Talaulikar, G. Mirsky, N. Triantafillis. |
| Date: | August 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8814 |
|
This document defines a way for a Border Gateway Protocol - LinkState (BGP-LS) speaker to advertise multiple types of supportedMaximum SID Depths (MSDs) at node and/or link granularity.
Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. |
|
| |
| RFC 8815 | Deprecating Any-Source Multicast (ASM) for Interdomain Multicast |
| |
| Authors: | M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert. |
| Date: | August 2020 |
| Formats: | txt xml pdf json html |
| Also: | BCP 0229 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 8815 |
|
This document recommends deprecation of the use of Any-SourceMulticast (ASM) for interdomain multicast. It recommends the use ofSource-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). |
|
| |
| RFC 8816 | Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases |
| |
| Authors: | E. Rescorla, J. Peterson. |
| Date: | February 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8816 |
|
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. |
|
| |
| RFC 8817 | RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec |
| |
| Authors: | V. Demjanenko, J. Punaro, D. Satterlee. |
| Date: | August 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8817 |
|
This document describes the RTP payload format for the TacticalSecure 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 LinearPrediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail. |
|
| |
| RFC 8818 | Distributed Mobility Anchoring |
| |
| Authors: | H. Chan, Ed., X. Wei, J. Lee, S. Jeon, CJ. Bernardos, Ed.. |
| Date: | October 2020 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8818 |
|
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. |
|
| |
| RFC 8819 | 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. |
|
| |
| RFC 8820 | 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.
This document provides guidance on the specification of URI substructure in standards.
This document obsoletes RFC 7320 and updates RFC 3986. |
|
| |
| RFC 8821 | PCE-Based Traffic Engineering (TE) in Native IP Networks |
| |
| Authors: | A. Wang, B. Khasanov, Q. Zhao, H. Chen. |
| Date: | April 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8821 |
|
This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and aPath Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation ElementCommunication Protocol (PCEP). |
|
| |
| RFC 8822 | 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) |
| |
| Authors: | D. Allan, Ed., D. Eastlake, D. Woolley. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8822 |
|
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). |
|
| |
| RFC 8823 | 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. |
|
| |
| RFC 8824 | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Minaburo, L. Toutain, R. Andreasen. |
| Date: | June 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8824 |
|
This document defines how to compress Constrained ApplicationProtocol (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. |
|
| |
| RFC 8825 | 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".
It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.
This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). |
|
| |
| RFC 8826 | 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. |
|
| |
| RFC 8827 | 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". |
|
| |
| RFC 8828 | 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. |
|
| |
| RFC 8829 | JavaScript Session Establishment Protocol (JSEP) |
| |
| Authors: | J. Uberti, C. Jennings, E. Rescorla, Ed.. |
| Date: | January 2021 |
| Formats: | txt xml json pdf html |
| Obsoleted by: | RFC 9429 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8829 |
|
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. |
|
| |
| RFC 8830 | 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.
This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication(WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling. |
|
| |
| RFC 8831 | WebRTC Data Channels |
| |
| Authors: | R. Jesup, S. Loreto, M. Tüxen. |
| Date: | January 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8831 |
|
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 TransmissionProtocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. |
|
| |
| RFC 8832 | WebRTC Data Channel Establishment Protocol |
| |
| Authors: | R. Jesup, S. Loreto, M. Tüxen. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8832 |
|
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. |
|
| |
| RFC 8833 | 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 TransmissionProtocol (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. |
|
| |
| RFC 8834 | Media Transport and Use of RTP in WebRTC |
| |
| Authors: | C. Perkins, M. Westerlund, J. Ott. |
| Date: | January 2021 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8834 |
|
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. |
|
| |
| RFC 8835 | Transports for WebRTC |
| |
|
|
This document describes the data transport protocols used by WebReal-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, andNAT boxes. |
|
| |
| RFC 8836 | Congestion Control Requirements for Interactive Real-Time Media |
| |
|
|
Congestion control is needed for all data transported across theInternet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique. |
|
| |
| RFC 8837 | Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS |
| |
| Authors: | P. Jones, S. Dhesikan, C. Jennings, D. Druta. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8837 |
|
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-TimeCommunication (WebRTC) traffic. |
|
| |
| RFC 8838 | Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol |
| |
|
|
This document describes "Trickle ICE", an extension to theInteractive Connectivity Establishment (ICE) protocol that enablesICE 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. |
|
| |
| RFC 8839 | 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 ConnectivityEstablishment (ICE) between the agents.
This document obsoletes RFCs 5245 and 6336. |
|
| |
| RFC 8840 | A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) |
| |
| Authors: | E. Ivov, T. Stach, E. Marocco, C. Holmberg. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8840 |
|
The Interactive Connectivity Establishment (ICE) protocol describes aNetwork Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
This document defines usage semantics for Trickle ICE with theSession Initiation Protocol (SIP). The document also defines a newSIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session DescriptionProtocol (SDP) "end-of-candidates" attribute and a new SIP option tag"trickle-ice" are defined. |
|
| |
| RFC 8841 | Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport |
| |
| Authors: | C. Holmberg, R. Shpount, S. Loreto, G. Camarillo. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8841 |
|
The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC8261 specifies how SCTP can be used on top of the Datagram TransportLayer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.
This specification defines the following new Session DescriptionProtocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations. |
|
| |
| RFC 8842 | 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 DatagramTransport 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.
This document defines a new SDP media-level attribute, "tls-id".
This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122. |
|
| |
| RFC 8843 | 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.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941. |
|
| |
| RFC 8844 | Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) |
| |
|
|
This document describes unknown key-share attacks on the use ofDatagram Transport Layer Security for the Secure Real-Time TransportProtocol (DTLS-SRTP). Similar attacks are described on the use ofDTLS-SRTP with the identity bindings used in Web Real-TimeCommunications (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. |
|
| |
| RFC 8845 | Framework for Telepresence Multi-Streams |
| |
| Authors: | M. Duckworth, Ed., A. Pepperell, S. Wenger. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8845 |
|
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 DescriptionProtocol (SDP) negotiation for setting up a telepresence session. |
|
| |
| RFC 8846 | An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model |
| |
| Authors: | R. Presta, S P. Romano. |
| Date: | January 2021 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8846 |
|
This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling MultipleStreams 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. |
|
| |
| RFC 8847 | 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 theIETF CLUE Working Group. A companion document, RFC 8848, delves intoCLUE signaling details as well as the SIP / Session DescriptionProtocol (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 TransmissionProtocol".) Message details, together with the behavior of CLUEParticipants acting as Media Providers and/or Media Consumers, are herein discussed. |
|
| |
| RFC 8848 | Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) |
| |
| Authors: | R. Hanton, P. Kyzivat, L. Xiao, C. Groves. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8848 |
|
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 SessionDescription Protocol (SDP), to produce a telepresence call. |
|
| |
| RFC 8849 | 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 forTelepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in theSession Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID). |
|
| |
| RFC 8850 | 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. |
|
| |
| RFC 8851 | 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.
This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document. |
|
| |
| RFC 8852 | RTP Stream Identifier Source Description (SDES) |
| |
| Authors: | A.B. Roach, S. Nandakumar, P. Thatcher. |
| Date: | January 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8852 |
|
This document defines and registers two new Real-time TransportControl Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification ofRTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream. |
|
| |
| RFC 8853 | Using Simulcast in Session Description Protocol (SDP) and RTP Sessions |
| |
| Authors: | B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8853 |
|
In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in differentRTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the SessionDescription 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. TheSDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. |
|
| |
| RFC 8854 | WebRTC Forward Error Correction Requirements |
| |
|
|
This document provides information and requirements for the use ofForward Error Correction (FEC) by WebRTC implementations. |
|
| |
| RFC 8855 | The Binary Floor Control Protocol (BFCP) |
| |
| Authors: | G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel. |
| Date: | January 2021 |
| Formats: | txt xml html pdf json |
| Obsoletes: | RFC 4582 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8855 |
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
This document obsoletes RFC 4582. |
|
| |
| RFC 8856 | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
|
This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary FloorControl Protocol (BFCP) streams.
This document obsoletes RFC 4583. |
|
| |
| RFC 8857 | The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) |
| |
| Authors: | V. Pascual, A. Román, S. Cazeaux, G. Salgueiro, R. Ravindranath. |
| Date: | January 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8857 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use ofBinary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios. |
|
| |
| RFC 8858 | Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This document defines a new Session Description Protocol (SDP) media- level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. |
|
| |
| RFC 8859 | A Framework for Session Description Protocol (SDP) Attributes When Multiplexing |
| |
|
|
The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session DescriptionProtocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.
This specification also categorizes the existing SDP attributes based on the framework described herein. |
|
| |
| RFC 8860 | Sending Multiple Types of Media in a Single RTP Session |
| |
|
|
This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text.This has been restricted by the RTP specifications (RFCs 3550 and3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. |
|
| |
| RFC 8861 | Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback |
| |
| Authors: | J. Lennox, M. Westerlund, Q. Wu, C. Perkins. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8861 |
|
RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP ControlProtocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a ReportingGroup extension to RTCP to reduce the reporting overhead in such scenarios. |
|
| |
| RFC 8862 | Best Practices for Securing RTP Media Signaled with SIP |
| |
|
|
Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. |
|
| |
| RFC 8863 | Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) |
| |
|
|
During the process of establishing peer-to-peer connectivity,Interactive Connectivity Establishment (ICE) agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur.
This document updates RFCs 8445 and 8838 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check. |
|
| |
| RFC 8864 | Negotiation Data Channels Using the Session Description Protocol (SDP) |
| |
| Authors: | K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8864 |
|
Data channel setup can be done using either the in-band Data ChannelEstablishment Protocol (DCEP) or some out-of-band non-DCEP protocol.This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. |
|
| |
| RFC 8865 | T.140 Real-Time Text Conversation over WebRTC Data Channels |
| |
|
|
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation(Recommendation ITU-T T.140) and how the Session Description Protocol(SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updatesRFC 8373 to specify its use with WebRTC data channels. |
|
| |
| RFC 8866 | SDP: Session Description Protocol |
| |
| Authors: | A. Begen, P. Kyzivat, C. Perkins, M. Handley. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 4566 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8866 |
|
This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. |
|
| |
| RFC 8867 | Test Cases for Evaluating Congestion Control for Interactive Real-Time Media |
| |
| Authors: | Z. Sarker, V. Singh, X. Zhu, M. Ramalho. |
| Date: | January 2021 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8867 |
|
The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment. |
|
| |
| RFC 8868 | Evaluating Congestion Control for Interactive Real-Time Media |
| |
| Authors: | V. Singh, J. Ott, S. Holmer. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8868 |
|
The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. |
|
| |
| RFC 8869 | Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks |
| |
|
|
The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well- functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks. |
|
| |
| RFC 8870 | Encrypted Key Transport for DTLS and Secure RTP |
| |
| Authors: | C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8870 |
|
Encrypted Key Transport (EKT) is an extension to DTLS (DatagramTransport Layer Security) and the Secure Real-time Transport Protocol(SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. |
|
| |
| RFC 8871 | A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC) |
| |
| Authors: | P. Jones, D. Benham, C. Groves. |
| Date: | January 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8871 |
|
This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where MediaDistributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP). |
|
| |
| RFC 8872 | Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams |
| |
| Authors: | M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even. |
| Date: | January 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8872 |
|
The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. |
|
| |
| RFC 8873 | Message Session Relay Protocol (MSRP) over Data Channels |
| |
|
|
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the MessageSession Relay Protocol (MSRP) and how the Session DescriptionProtocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported: the connection of two MSRP data channel endpoints; and a gateway configuration, which connects an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS.This document updates RFC 4975. |
|
| |
| RFC 8874 | Working Group GitHub Usage Guidance |
| |
|
|
This document provides a set of guidelines for working groups that choose to use GitHub for their work. |
|
| |
| RFC 8875 | Working Group GitHub Administration |
| |
|
|
The use of GitHub in IETF working group processes is increasing.This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub. |
|
| |
| RFC 8876 | Non-interactive Emergency Calls |
| |
| Authors: | B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens. |
| Date: | September 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8876 |
|
Use of the Internet for emergency calling is described in RFC 6443,'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIPMESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. |
|
| |
| RFC 8877 | Guidelines for Defining Packet Timestamps |
| |
| Authors: | T. Mizrahi, J. Fabini, A. Morton. |
| Date: | September 2020 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8877 |
|
Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as"packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. |
|
| |
| RFC 8878 | Zstandard Compression and the 'application/zstd' Media Type |
| |
|
|
Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.
Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.
This document replaces and obsoletes RFC 8478. |
|
| |
| RFC 8879 | TLS Certificate Compression |
| |
| Authors: | A. Ghedini, V. Vasiliev. |
| Date: | December 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8879 |
|
In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.
This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. |
|
| |
| RFC 8880 | Special Use Domain Name 'ipv4only.arpa' |
| |
|
|
NAT64 (Network Address and Protocol Translation from IPv6 Clients toIPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.
The specification for how a client discovers its local network'sNAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.
Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use DomainNames registry as a name with special properties.
This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name.It also adds similar declarations for the corresponding reverse mapping names. |
|
| |
| RFC 8881 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.
This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. |
|
| |
| RFC 8882 | DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements |
| |
|
|
DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service. |
|
| |
| RFC 8883 | ICMPv6 Errors for Discarding Packets Due to Processing Limits |
| |
|
|
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits.When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets.This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards. |
|
| |
| RFC 8884 | Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios |
| |
| Authors: | J. Seedorf, M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi. |
| Date: | October 2020 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8884 |
|
Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts. This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking ResearchGroup (ICNRG). |
|
| |
| RFC 8885 | Proxy Mobile IPv6 Extensions for Distributed Mobility Management |
| |
| Authors: | CJ. Bernardos, A. de la Oliva, F. Giust, JC. Zúñiga, A. Mourad. |
| Date: | October 2020 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8885 |
|
Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.
There are many different approaches to address Distributed MobilityManagement -- for example, extending network-based mobility protocols(like Proxy Mobile IPv6) or client-based mobility protocols (likeMobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways. |
|
| |
| RFC 8886 | Secure Device Install |
| |
|
|
Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support.In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device. |
|
| |
| RFC 8887 | A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket |
| |
|
|
This document defines a binding for the JSON Meta ApplicationProtocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. |
|
| |
| RFC 8888 | RTP Control Protocol (RTCP) Feedback for Congestion Control |
| |
| Authors: | Z. Sarker, C. Perkins, V. Singh, M. Ramalho. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8888 |
|
An effective RTP congestion control algorithm requires more fine- grained feedback on packet loss, timing, and Explicit CongestionNotification (ECN) marks than is provided by the standard RTP ControlProtocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. |
|
| |
| RFC 8889 | Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto. |
| Date: | August 2020 |
| Formats: | txt html pdf xml json |
| Obsoleted by: | RFC 9342 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8889 |
|
The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking". |
|
| |
| RFC 8890 | The Internet is for End Users |
| |
|
|
This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. |
|
| |
| RFC 8891 | GOST R 34.12-2015: Block Cipher "Magma" |
| |
|
|
In addition to a new cipher with a block length of n=128 bits(referred to as "Kuznyechik" and described in RFC 7801), RussianFederal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher inInternet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption. |
|
| |
| RFC 8892 | Guidelines and Registration Procedures for Interface Types and Tunnel Types |
| |
|
|
This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANAConsiderations sections and YANG modules, so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC2863 and provides updated guidance for these registries. |
|
| |
| RFC 8893 | Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export |
| |
|
|
A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.This document updates RFC 6811. |
|
| |
| RFC 8894 | Simple Certificate Enrolment Protocol |
| |
|
|
This document specifies the Simple Certificate Enrolment Protocol(SCEP), a PKI protocol that leverages existing technology by usingCryptographic Message Syntax (CMS, formerly known as PKCS #7) andPKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. |
|
| |
| RFC 8895 | Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) |
| |
|
|
The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. |
|
| |
| RFC 8896 | Application-Layer Traffic Optimization (ALTO) Cost Calendar |
| |
| Authors: | S. Randriamasy, R. Yang, Q. Wu, L. Deng, N. Schwan. |
| Date: | November 2020 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8896 |
|
This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTOCost Calendar with which an ALTO Server exposes ALTO cost values inJSON arrays where each value corresponds to a given time interval.The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. |
|
| |
| RFC 8897 | Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties |
| |
|
|
This document provides a single reference point for requirements forRelying Party (RP) software for use in the Resource Public KeyInfrastructure (RPKI). It cites requirements that appear in severalRPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. |
|
| |
| RFC 8898 | Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) |
| |
|
|
This document defines the "Bearer" authentication scheme for theSession Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core1.0. This document updates RFC 3261 to provide guidance on how a SIPUser Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. |
|
| |
| RFC 8899 | Packetization Layer Path MTU Discovery for Datagram Transports |
| |
|
|
This document specifies Datagram Packetization Layer Path MTUDiscovery (DPLPMTUD). This is a robust method for Path MTU Discovery(PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.
The document provides implementation notes for incorporating DatagramPMTUD into IETF datagram transports or applications that use datagram transports.
This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. |
|
