RFC Abstracts

RFC8620 - The JSON Meta Application Protocol (JMAP)
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.
RFC8619 - Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.
RFC8618 - Compacted-DNS (C-DNS): A Format for DNS Packet Capture
This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications.
RFC8617 - The Authenticated Received Chain (ARC) Protocol
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
RFC8616 - Email Authentication for Internationalized Mail
Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.
RFC8615 - Well-Known Uniform Resource Identifiers (URIs)
This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.
RFC8614 - Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)
This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.
RFC8613 - Object Security for Constrained RESTful Environments (OSCORE)
This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
RFC8612 - DDoS Open Threat Signaling (DOTS) Requirements
This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.
RFC8611 - Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
RFC8610 - Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.
RFC8609 - Content-Centric Networking (CCNx) Messages in TLV Format
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
RFC8608 - BGPsec Algorithms, Key Formats, and Signature Formats
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.
RFC8607 - Calendaring Extensions to WebDAV (CalDAV): Managed Attachments
This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.
RFC8606 - ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field
The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose.
RFC8605 - vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.
RFC8604 - Interconnecting Millions of Endpoints with Segment Routing
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.
RFC8603 - Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
RFC8602 - Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses
This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.
RFC8601 - Message Header Field for Indicating Message Authentication Status
This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.
RFC8600 - Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).
RFC8599 - Push Notification with the Session Initiation Protocol (SIP)
This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.
RFC8598 - Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)
This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.
RFC8597 - Cooperating Layered Architecture for Software-Defined Networking (CLAS)
Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.
RFC8596 - MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)
This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.
RFC8595 - An MPLS-Based Forwarding Plane for Service Function Chaining
This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.
RFC8594 - The Sunset HTTP Header Field
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.
RFC8593 - Video Traffic Models for RTP Congestion Control Evaluations
This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.
RFC8592 - Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)
This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.
RFC8591 - SIP-Based Messaging with S/MIME
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.
RFC8590 - Change Poll Extension for the Extensible Provisioning Protocol (EPP)
This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.
RFC8589 - The 'leaptofrogans' URI Scheme
This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites.
RFC8588 - Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.
RFC8587 - NFS Version 4.0 Trunking Update
In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.
RFC8586 - Loop Detection in Content Delivery Networks (CDNs)
This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.
RFC8585 - Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
RFC8584 - Framework for Ethernet VPN Designated Forwarder Election Extensibility
An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).
RFC8583 - Diameter Load Information Conveyance
RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.
RFC8582 - Diameter Overload Rate Control
This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.
RFC8581 - Diameter Agent Overload and the Peer Overload Report
This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.
RFC8580 - Sieve Extension: File Carbon Copy (FCC)
The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.
RFC8579 - Sieve Email Filtering: Delivering to Special-Use Mailboxes
The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.
RFC8578 - Deterministic Networking Use Cases
This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.
RFC8577 - Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane
As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
RFC8576 - Internet of Things (IoT) Security: State of the Art and Challenges
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
RFC8575 - YANG Data Model for the Precision Time Protocol (PTP)
This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).
RFC8574 - cite-as: A Link Relation to Convey a Preferred URI for Referencing
A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.
RFC8573 - Message Authentication Code for the Network Time Protocol
The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.
RFC8572 - Secure Zero Touch Provisioning (SZTP)
This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.
RFC8571 - BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.