RFC Abstracts
RFC8456 - Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance
This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.
RFC8455 - Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.
RFC8454 - Information Model for Abstraction and Control of TE Networks (ACTN)
This document provides an information model for Abstraction and Control of TE Networks (ACTN).
RFC8453 - Framework for Abstraction and Control of TE Networks (ACTN)
Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.
RFC8452 - AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.
RFC8451 - Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API
This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.
RFC8450 - RTP Payload Format for VC-2 High Quality (HQ) Profile
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
RFC8449 - Record Size Limit Extension for TLS
An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.
RFC8448 - Example Handshake Traces for TLS 1.3
This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.
RFC8447 - IANA Registry Updates for TLS and DTLS
This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.
RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
RFC8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
RFC8444 - OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.
RFC8443 - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.
RFC8442 - ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.
RFC8441 - Bootstrapping WebSockets with HTTP/2
This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.
RFC8440 - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.
RFC8439 - ChaCha20 and Poly1305 for IETF Protocols
This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.
RFC8438 - IMAP Extension for STATUS=SIZE
This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.
RFC8437 - IMAP UNAUTHENTICATE Extension for Connection Reuse
This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.
RFC8436 - Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.
RFC8435 - Parallel NFS (pNFS) Flexible File Layout
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.
RFC8434 - Requirements for Parallel NFS (pNFS) Layout Types
This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.
RFC8433 - A Simpler Method for Resolving Alert-Info URNs
The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.
RFC8432 - A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters
The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.
RFC8431 - A YANG Data Model for the Routing Information Base (RIB)
This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.
RFC8430 - RIB Information Model
Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.
RFC8429 - Deprecate Triple-DES (3DES) and RC4 in Kerberos
The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.
RFC8428 - Sensor Measurement Lists (SenML)
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
RFC8427 - Representing DNS Messages in JSON
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.
RFC8426 - Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.
RFC8425 - IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.
RFC8424 - Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.
RFC8423 - Reclassification of Suite B Documents to Historic Status
This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.
RFC8422 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.
RFC8421 - Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).
RFC8420 - Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).
RFC8419 - Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)
This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.
RFC8418 - Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).
RFC8417 - Security Event Token (SET)
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.
RFC8416 - Simplified Local Internet Number Resource Management with the RPKI (SLURM)
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.
RFC8415 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).
RFC8414 - OAuth 2.0 Authorization Server Metadata
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
RFC8413 - Framework for Scheduled Use of Resources
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
RFC8412 - Software Inventory Message and Attributes (SWIMA) for PA-TNC
This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).
RFC8411 - IANA Registration for the Cryptographic Algorithm Object Identifier Range
When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.
RFC8410 - Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.
RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types
This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.
RFC8408 - Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.
RFC8407 - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.
This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.
RFC8455 - Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance
This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.
RFC8454 - Information Model for Abstraction and Control of TE Networks (ACTN)
This document provides an information model for Abstraction and Control of TE Networks (ACTN).
RFC8453 - Framework for Abstraction and Control of TE Networks (ACTN)
Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.
RFC8452 - AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.
RFC8451 - Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API
This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.
RFC8450 - RTP Payload Format for VC-2 High Quality (HQ) Profile
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
RFC8449 - Record Size Limit Extension for TLS
An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.
RFC8448 - Example Handshake Traces for TLS 1.3
This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.
RFC8447 - IANA Registry Updates for TLS and DTLS
This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.
RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
RFC8445 - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
RFC8444 - OSPFv2 Extensions for Bit Index Explicit Replication (BIER)
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.
RFC8443 - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.
RFC8442 - ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.
RFC8441 - Bootstrapping WebSockets with HTTP/2
This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.
RFC8440 - IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.
RFC8439 - ChaCha20 and Poly1305 for IETF Protocols
This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.
RFC8438 - IMAP Extension for STATUS=SIZE
This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.
RFC8437 - IMAP UNAUTHENTICATE Extension for Connection Reuse
This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.
RFC8436 - Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.
RFC8435 - Parallel NFS (pNFS) Flexible File Layout
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.
RFC8434 - Requirements for Parallel NFS (pNFS) Layout Types
This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.
RFC8433 - A Simpler Method for Resolving Alert-Info URNs
The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.
RFC8432 - A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters
The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.
RFC8431 - A YANG Data Model for the Routing Information Base (RIB)
This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.
RFC8430 - RIB Information Model
Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.
RFC8429 - Deprecate Triple-DES (3DES) and RC4 in Kerberos
The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.
RFC8428 - Sensor Measurement Lists (SenML)
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
RFC8427 - Representing DNS Messages in JSON
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.
RFC8426 - Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.
RFC8425 - IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.
RFC8424 - Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.
RFC8423 - Reclassification of Suite B Documents to Historic Status
This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.
RFC8422 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.
RFC8421 - Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).
RFC8420 - Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).
RFC8419 - Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)
This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.
RFC8418 - Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)
This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).
RFC8417 - Security Event Token (SET)
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.
RFC8416 - Simplified Local Internet Number Resource Management with the RPKI (SLURM)
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.
RFC8415 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).
RFC8414 - OAuth 2.0 Authorization Server Metadata
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
RFC8413 - Framework for Scheduled Use of Resources
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.
RFC8412 - Software Inventory Message and Attributes (SWIMA) for PA-TNC
This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).
RFC8411 - IANA Registration for the Cryptographic Algorithm Object Identifier Range
When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.
RFC8410 - Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.
RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types
This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.
RFC8408 - Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.
RFC8407 - Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.