| |
| RFC 9000 | QUIC: A UDP-Based Multiplexed and Secure Transport |
| |
| Authors: | J. Iyengar, Ed., M. Thomson, Ed.. |
| Date: | May 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9000 |
|
This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration ofTLS for key negotiation, loss detection, and an exemplary congestion control algorithm. |
|
| |
| RFC 9001 | Using TLS to Secure QUIC |
| |
| Authors: | M. Thomson, Ed., S. Turner, Ed.. |
| Date: | May 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9001 |
|
This document describes how Transport Layer Security (TLS) is used to secure QUIC. |
|
| |
| RFC 9002 | QUIC Loss Detection and Congestion Control |
| |
| Authors: | J. Iyengar, Ed., I. Swett, Ed.. |
| Date: | May 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9002 |
|
This document describes loss detection and congestion control mechanisms for QUIC. |
|
| |
| RFC 9003 | Extended BGP Administrative Shutdown Communication |
| |
|
|
This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP AdministrativeShutdown Communication of up to 255 octets to improve communication using multibyte character sets. |
|
| |
| RFC 9004 | Updates for the Back-to-Back Frame Benchmark in RFC 2544 |
| |
|
|
Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.
This memo updates Section 26.4 of RFC 2544. |
|
| |
| RFC 9005 | Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) |
| |
| Authors: | S. Litkowski, S. Sivabalan, J. Tantsura, J. Hardwick, C. Li. |
| Date: | March 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9005 |
|
This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to thePath Computation Element Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group(PAG). |
|
| |
| RFC 9006 | TCP Usage Guidance in the Internet of Things (IoT) |
| |
| Authors: | C. Gomez, J. Crowcroft, M. Scharf. |
| Date: | March 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9006 |
|
This document provides guidance on how to implement and use theTransmission Control Protocol (TCP) in Constrained-Node Networks(CNNs), which are a characteristic of the Internet of Things (IoT).Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use. |
|
| |
| RFC 9007 | Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies a data model for handling Message DispositionNotifications (MDNs) (see RFC 8098) in the JSON Meta ApplicationProtocol (JMAP) (see RFCs 8620 and 8621). |
|
| |
| RFC 9008 | Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane |
| |
|
|
This document looks at different data flows through Low-Power andLossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type(RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to theRPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed. |
|
| |
| RFC 9009 | Efficient Route Invalidation |
| |
| Authors: | R.A. Jadhav, Ed., P. Thubert, R.N. Sahoo, Z. Cao. |
| Date: | April 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9009 |
|
This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "DestinationCleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging. |
|
| |
| RFC 9010 | Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves |
| |
|
|
This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. |
|
| |
| RFC 9011 | Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN |
| |
| Authors: | O. Gimenez, Ed., I. Petrov, Ed.. |
| Date: | April 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9011 |
|
The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.
This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation. |
|
| |
| RFC 9012 | The BGP Tunnel Encapsulation Attribute |
| |
|
|
This document defines a BGP path attribute known as the "TunnelEncapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.
This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any TunnelEncapsulation attribute where load balancing is desired. |
|
| |
| RFC 9013 | OSPF Advertisement of Tunnel Encapsulations |
| |
| Authors: | X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil. |
| Date: | April 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9013 |
|
Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF RouterInformation Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. |
|
| |
| RFC 9014 | Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake. |
| Date: | May 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9014 |
|
This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend theLayer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EthernetVirtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services(VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as theInterconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data CenterNetwork Virtualization Edge (NVE) devices. |
|
| |
| RFC 9015 | BGP Control Plane for the Network Service Header in Service Function Chaining |
| |
| Authors: | A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil. |
| Date: | June 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9015 |
|
This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service FunctionChain (SFC) Address Family Identifier / Subsequent Address FamilyIdentifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides"instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.
This document adopts the service function chaining architecture described in RFC 7665. |
|
| |
| RFC 9016 | Flow and Service Information Model for Deterministic Networking (DetNet) |
| |
| Authors: | B. Varga, J. Farkas, R. Cummings, Y. Jiang, D. Fedyk. |
| Date: | March 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9016 |
|
This document describes the flow and service information model forDeterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes. |
|
| |
| RFC 9017 | Special-Purpose Label Terminology |
| |
|
|
This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.
This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator(7) when immediately preceded by the Extension Label (15).
This document updates RFCs 3032 and 7274. |
|
| |
| RFC 9018 | Interoperable Domain Name System (DNS) Server Cookies |
| |
| Authors: | O. Sury, W. Toorop, D. Eastlake 3rd, M. Andrews. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 7873 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9018 |
|
DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers.
This document updates RFC 7873 with precise directions for creatingServer Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. AnIANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry. |
|
| |
| RFC 9019 | A Firmware Update Architecture for Internet of Things |
| |
| Authors: | B. Moran, H. Tschofenig, D. Brown, M. Meriac. |
| Date: | April 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9019 |
|
Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.
In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. |
|
| |
| RFC 9020 | YANG Data Model for Segment Routing |
| |
| Authors: | S. Litkowski, Y. Qu, A. Lindem, P. Sarkar, J. Tantsura. |
| Date: | May 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9020 |
|
This document defines three YANG data models. The first is forSegment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is aYANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane. |
|
| |
| RFC 9021 | Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) |
| |
|
|
This document specifies the conventions for using the Walnut DigitalSignature Algorithm (WalnutDSA) for digital signatures with the CBORObject Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on GroupTheoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.
The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties ofWalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF.
WalnutDSA and the Walnut Digital Signature Algorithm are trademarks of Veridify Security Inc. |
|
| |
| RFC 9022 | Domain Name Registration Data (DNRD) Objects Mapping |
| |
| Authors: | G. Lozano, J. Gould, C. Thippeswamy. |
| Date: | May 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9022 |
|
This document specifies the format, contents, and semantics of DomainName Registration Data (DNRD) escrow deposits for a domain name registry. |
|
| |
| RFC 9023 | Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. |
| Date: | June 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9023 |
|
This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network.This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs. |
|
| |
| RFC 9024 | Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant, D. Fedyk. |
| Date: | June 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9024 |
|
This document specifies the Deterministic Networking data plane whenTime-Sensitive Networking (TSN) networks are interconnected over aDetNet MPLS network. |
|
| |
| RFC 9025 | Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9025 |
|
This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology. |
|
| |
| RFC 9026 | Multicast VPN Fast Upstream Failover |
| |
| Authors: | T. Morin, Ed., R. Kebler, Ed., G. Mirsky, Ed.. |
| Date: | April 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9026 |
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using"Bidirectional Forwarding Detection (BFD) for Multipoint Networks"(RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGPMulticast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE. |
|
| |
| RFC 9027 | Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks |
| |
|
|
This document adds new assertion values for a Resource PriorityHeader ("rph") claim and a new SIP Priority Header ("sph") claim for protection of the "psap-callback" value as part of the "rph" PersonalAssertion Token (PASSporT) extension in support of the security of emergency services networks for emergency call origination and callback. |
|
| |
| RFC 9028 | Native NAT Traversal Mode for the Host Identity Protocol |
| |
| Authors: | A. Keränen, J. Melén, M. Komu, Ed.. |
| Date: | July 2021 |
| Formats: | txt xml pdf html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9028 |
|
This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP. |
|
| |
| RFC 9029 | Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries |
| |
|
|
RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).IANA created a registry consistent with that document called "BorderGateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.
This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts. |
|
| |
| RFC 9030 | An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) |
| |
|
|
This document describes a network architecture that provides low- latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications. |
|
| |
| RFC 9031 | Constrained Join Protocol (CoJP) for 6TiSCH |
| |
| Authors: | M. Vučinić, Ed., J. Simon, K. Pister, M. Richardson. |
| Date: | May 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9031 |
|
This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over theTime-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a singleCoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTfulEnvironments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR(Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. |
|
| |
| RFC 9032 | Encapsulation of 6TiSCH Join and Enrollment Information Elements |
| |
| Authors: | D. Dujovne, Ed., M. Richardson. |
| Date: | May 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9032 |
|
In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit EnhancedBeacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities. |
|
| |
| RFC 9033 | 6TiSCH Minimal Scheduling Function (MSF) |
| |
| Authors: | T. Chang, Ed., M. Vučinić, X. Vilajosana, S. Duquennoy, D. Dujovne. |
| Date: | May 2021 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9033 |
|
This specification defines the "IPv6 over the TSCH mode of IEEE802.15.4" (6TiSCH) Minimal Scheduling Function (MSF). ThisScheduling Function describes both the behavior of a node when joining the network and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH OperationSublayer Protocol (6P) and the minimal security framework for 6TiSCH. |
|
| |
| RFC 9034 | Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | L. Thomas, S. Anamalamudi, S.V.R. Anand, M. Hegde, C. Perkins. |
| Date: | June 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9034 |
|
This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks. |
|
| |
| RFC 9035 | A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header |
| |
|
|
This document updates RFC 8138 by defining a bit in the RoutingProtocol for Low-Power and Lossy Networks (RPL) Destination-OrientedDirected Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset. |
|
| |
| RFC 9036 | Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy |
| |
|
|
This document changes the policy of the "Location-to-ServiceTranslation (LoST) Location Profiles" IANA registry established byRFC 5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. |
|
| |
| RFC 9037 | Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. |
| Date: | June 2021 |
| Formats: | txt pdf json xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9037 |
|
This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-SensitiveNetworking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referencedRFCs. |
|
| |
| RFC 9038 | Extensible Provisioning Protocol (EPP) Unhandled Namespaces |
| |
|
|
The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730. |
|
| |
| RFC 9039 | Uniform Resource Names for Device Identifiers |
| |
| Authors: | J. Arkko, C. Jennings, Z. Shelby. |
| Date: | June 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9039 |
|
This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information. |
|
| |
| RFC 9040 | TCP Control Block Interdependence |
| |
|
|
This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCPControl Blocks, among similar concurrent or consecutive connections. |
|
| |
| RFC 9041 | Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry |
| |
|
|
This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "VendorPrivate Use") has been changed to "First Come First Served" for theTLV and sub-TLV registries.
It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoletedRFC 5226 (both titled "Guidelines for Writing an IANA ConsiderationsSection in RFCs"). |
|
| |
| RFC 9042 | Sieve Email Filtering: Delivery by MAILBOXID |
| |
|
|
The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.
This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes. |
|
| |
| RFC 9043 | FFV1 Video Coding Format Versions 0, 1, and 3 |
| |
| Authors: | M. Niedermayer, D. Rice, J. Martinez. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9043 |
|
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. |
|
| |
| RFC 9044 | Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the AES-GMACMessage Authentication Code algorithm with the Cryptographic MessageSyntax (CMS) as specified in RFC 5652. |
|
| |
| RFC 9045 | Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) |
| |
|
|
This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211. |
|
| |
| RFC 9046 | Babel Information Model |
| |
|
|
The Babel information model provides structured data elements for aBabel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. This information model only includes parameters and parameter values useful for managing Babel over IPv6. |
|
| |
| RFC 9047 | Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, W. Lin. |
| Date: | June 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9047 |
|
This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control(MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function onIntegrated Routing and Bridging (IRB) interfaces can reply to ARPRequests or Neighbor Solicitation (NS) messages with the correct information. |
|
| |
| RFC 9048 | Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') |
| |
|
|
The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC5448 (EAP-AKA') was an improved version of EAP-AKA.
This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.
EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.
This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'.This document updates both RFCs 4187 and 5448. |
|
| |
| RFC 9049 | Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken) |
| |
|
|
This document is a product of the Path Aware Networking ResearchGroup (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy PathAware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons forPath Aware networking researchers.
This document contains that catalog and analysis. |
|
| |
| RFC 9050 | Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs |
| |
| Authors: | Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou. |
| Date: | July 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9050 |
|
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LabelSwitched Path (LSP) can be calculated/set up/initiated and the label- forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.
This document specifies the procedures and Path Computation ElementCommunication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP. |
|
| |
| RFC 9051 | Internet Message Access Protocol (IMAP) - Version 4rev2 |
| |
|
|
The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.
IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified inRFC 6409. |
|
| |
| RFC 9052 | CBOR Object Signing and Encryption (COSE): Structures and Process |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152. |
|
| |
| RFC 9053 | CBOR Object Signing and Encryption (COSE): Initial Algorithms |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBORObject Signing and Encryption (COSE) protocol (RFC 9052).
This document, along with RFC 9052, obsoletes RFC 8152. |
|
| |
| RFC 9054 | CBOR Object Signing and Encryption (COSE): Hash Algorithms |
| |
|
|
The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. |
|
| |
| RFC 9055 | Deterministic Networking (DetNet) Security Considerations |
| |
| Authors: | E. Grossman, Ed., T. Mizrahi, A. Hacker. |
| Date: | June 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9055 |
|
A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e.,"jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.
This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.
This document also addresses security considerations specific to theIP and MPLS data plane technologies, thereby complementing theSecurity Considerations sections of those documents. |
|
| |
| RFC 9056 | Deterministic Networking (DetNet) Data Plane: IP over MPLS |
| |
| Authors: | B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen. |
| Date: | October 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9056 |
|
This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network. |
|
| |
| RFC 9057 | Email Author Header Field |
| |
|
|
Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field.This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.
The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification byMediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy. |
|
| |
| RFC 9058 | Multilinear Galois Mode (MGM) |
| |
| Authors: | S. Smyshlyaev, Ed., V. Nozdrunov, V. Shishkin, E. Griboedova. |
| Date: | June 2021 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9058 |
|
Multilinear Galois Mode (MGM) is an Authenticated Encryption withAssociated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.
MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 andIPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher. |
|
| |
| RFC 9059 | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | R. Gandhi, Ed., C. Barth, B. Wen. |
| Date: | June 2021 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9059 |
|
This document defines Path Computation Element Communication Protocol(PCEP) extensions for grouping two unidirectional MPLS-TE LabelSwitched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiatedLSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling. |
|
| |
| RFC 9060 | Secure Telephone Identity Revisited (STIR) Certificate Delegation |
| |
|
|
The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing.This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. |
|
| |
| RFC 9061 | A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) |
| |
| Authors: | R. Marin-Lopez, G. Lopez-Millan, F. Pereniguez-Garcia. |
| Date: | July 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9061 |
|
This document describes how to provide IPsec-based flow protection(integrity and confidentiality) by means of an Interface to NetworkSecurity Function (I2NSF) Controller. It considers two main well- known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSFController to one or several flow-based Network Security Functions(NSFs) that rely on IPsec to protect data traffic.
This document focuses on the I2NSF NSF-Facing Interface by providingYANG data models for configuring the IPsec databases, namely SecurityPolicy Database (SPD), Security Association Database (SAD), PeerAuthorization Database (PAD), and Internet Key Exchange Version 2(IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol. |
|
| |
| RFC 9062 | Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | S. Salam, A. Sajassi, S. Aldrin, J. Drake, D. Eastlake 3rd. |
| Date: | June 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9062 |
|
This document specifies the requirements and reference framework forEthernet VPN (EVPN) Operations, Administration, and Maintenance(OAM). The requirements cover the OAM aspects of EVPN and ProviderBackbone Bridge EVPN (PBB-EVPN). The framework defines the layeredOAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers. |
|
| |
| RFC 9063 | Host Identity Protocol Architecture |
| |
|
|
This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of theHI namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The SecurityConsiderations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. |
|
| |
| RFC 9064 | Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols |
| |
|
|
This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher- layer QoS objectives. It explicitly excludes any discussion ofQuality of Experience (QoE), which can only be assessed and controlled at the application layer or above.
This document is not a product of the IRTF Information-CentricNetworking Research Group (ICNRG) but has been through formal LastCall and has the support of the participants in the research group for publication as an individual submission. |
|
| |
| RFC 9065 | Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols |
| |
|
|
To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.
This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features. |
|
| |
| RFC 9066 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home |
| |
| Authors: | T. Reddy.K, M. Boucadair, Ed., J. Shallow. |
| Date: | December 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9066 |
|
This document specifies the Denial-of-Service Open Threat Signaling(DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client.The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).
The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to blockDDoS attack traffic closer to the source(s) of a DDoS attack. |
|
| |
| RFC 9067 | A YANG Data Model for Routing Policy |
| |
| Authors: | Y. Qu, J. Tantsura, A. Lindem, X. Liu. |
| Date: | October 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9067 |
|
This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism. |
|
| |
| RFC 9068 | JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens |
| |
|
|
This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. |
|
| |
| RFC 9069 | Support for Local RIB in the BGP Monitoring Protocol (BMP) |
| |
| Authors: | T. Evens, S. Bayraktar, M. Bhardwaj, P. Lucente. |
| Date: | February 2022 |
| Formats: | txt json xml pdf html |
| Updates: | RFC 7854 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9069 |
|
The BGP Monitoring Protocol (BMP) defines access to local RoutingInformation Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. |
|
| |
| RFC 9070 | YANG Data Model for MPLS LDP |
| |
| Authors: | K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah. |
| Date: | March 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9070 |
|
This document describes a YANG data model for the Multiprotocol LabelSwitching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA). |
|
| |
| RFC 9071 | RTP-Mixer Formatting of Multiparty Real-Time Text |
| |
|
|
This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time TransportProtocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.
Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.
A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".
This document updates RFC 4103 ("RTP Payload for Text Conversation").
A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided. |
|
| |
| RFC 9072 | Extended Optional Parameters Length for BGP OPEN Message |
| |
|
|
The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concerns about this limitation.
This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in a BGP OPEN message.The Parameter Length field of individual Optional Parameters is also extended. |
|
| |
| RFC 9073 | Event Publishing Extensions to iCalendar |
| |
|
|
This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.
This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data. |
|
| |
| RFC 9074 | "VALARM" Extensions for iCalendar |
| |
|
|
This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers.
This document updates RFC 5545. |
|
| |
| RFC 9075 | Report from the IAB COVID-19 Network Impacts Workshop 2020 |
| |
| Authors: | J. Arkko, S. Farrell, M. Kühlewind, C. Perkins. |
| Date: | July 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9075 |
|
The Coronavirus disease (COVID-19) pandemic caused changes inInternet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.
The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9076 | DNS Privacy Considerations |
| |
|
|
This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. |
|
| |
| RFC 9077 | NSEC and NSEC3: TTLs and Aggressive Use |
| |
|
|
Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198. |
|
| |
| RFC 9078 | Reaction: Indicating Summary Reaction to a Message |
| |
| Authors: | D. Crocker, R. Signes, N. Freed. |
| Date: | August 2021 |
| Formats: | txt json pdf xml html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9078 |
|
The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail. |
|
| |
| RFC 9079 | Source-Specific Routing in the Babel Routing Protocol |
| |
| Authors: | M. Boutier, J. Chroboczek. |
| Date: | August 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9079 |
|
Source-specific routing, also known as Source Address DependentRouting (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol. |
|
| |
| RFC 9080 | Homenet Profile of the Babel Routing Protocol |
| |
|
|
This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of theHomenet protocol suite, as well as the interactions between the HomeNetworking Control Protocol (HNCP) and Babel. |
|
| |
| RFC 9081 | Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes |
| |
|
|
This document specifies the procedures for interoperation betweenMulticast Virtual Private Network (MVPN) Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the Provider Edge (PE) routers that are customer MSDP peers. This document updates RFC 6514. |
|
| |
| RFC 9082 | Registration Data Access Protocol (RDAP) Query Format |
| |
|
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP). This document obsoletes RFC 7482. |
|
| |
| RFC 9083 | JSON Responses for the Registration Data Access Protocol (RDAP) |
| |
|
|
This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. |
|
| |
| RFC 9084 | OSPF Prefix Originator Extensions |
| |
| Authors: | A. Wang, A. Lindem, J. Dong, P. Psenak, K. Talaulikar, Ed.. |
| Date: | August 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9084 |
|
This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering. |
|
| |
| RFC 9085 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing |
| |
| Authors: | S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen. |
| Date: | August 2021 |
| Formats: | txt xml json pdf html |
| Updated by: | RFC 9356 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9085 |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called"segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.
This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) address family in order to carry SR information via BGP. |
|
| |
| RFC 9086 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering |
| |
| Authors: | S. Previdi, K. Talaulikar, Ed., C. Filsfils, K. Patel, S. Ray, J. Dong. |
| Date: | August 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9086 |
|
A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per- flow state only at the ingress node of the SR domain.
This document describes an extension to Border Gateway Protocol -Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP EgressPeer Engineering (EPE) policies and strategies can be computed based on Segment Routing. |
|
| |
| RFC 9087 | Segment Routing Centralized BGP Egress Peer Engineering |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9087 |
|
Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.
This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-basedBGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. |
|
| |
| RFC 9088 | Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS |
| |
| Authors: | X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. |
| Date: | August 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9088 |
|
Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingIS-IS and Border Gateway Protocol - Link State (BGP-LS). |
|
| |
| RFC 9089 | Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF |
| |
| Authors: | X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. |
| Date: | August 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9089 |
|
Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingOSPFv2 and OSPFv3, and Border Gateway Protocol - Link State (BGP-LS). |
|
| |
| RFC 9090 | Concise Binary Object Representation (CBOR) Tags for Object Identifiers |
| |
|
|
The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. |
|
| |
| RFC 9091 | Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains |
| |
| Authors: | S. Kitterman, T. Wicinski, Ed.. |
| Date: | July 2021 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9091 |
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail- receiving organization can use to improve mail handling.
DMARC distinguishes the portion of a name that is a Public SuffixDomain (PSD), below which Organizational Domain names are created.The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.
Some implementations of DMARC consider a PSD to be ineligible forDMARC enforcement. This specification addresses that case. |
|
| |
| RFC 9092 | Finding and Using Geofeed Data |
| |
| Authors: | R. Bush, M. Candela, W. Kumari, R. Housley. |
| Date: | July 2021 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9092 |
|
This document specifies how to augment the Routing PolicySpecification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files. |
|
| |
| RFC 9093 | A YANG Data Model for Layer 0 Types |
| |
| Authors: | H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. |
| Date: | August 2021 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9093 |
|
This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-gridDense Wavelength Division Multiplexing (DWDM) networks. |
|
| |
| RFC 9094 | A YANG Data Model for Wavelength Switched Optical Networks (WSONs) |
| |
| Authors: | H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. |
| Date: | August 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9094 |
|
This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength SwitchedOptical Networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9095 | Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration |
| |
| Authors: | J. Yao, L. Zhou, H. Li, N. Kong, J. Xie. |
| Date: | July 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9095 |
|
This document describes an extension of Extensible ProvisioningProtocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names.Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a nonstandard proprietary extension. |
|
| |
| RFC 9096 | Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events |
| |
|
|
This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084. |
|
| |
| RFC 9097 | Metrics and Methods for One-Way IP Capacity |
| |
| Authors: | A. Morton, R. Geib, L. Ciavattone. |
| Date: | November 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9097 |
|
This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical MaximumIP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement. |
|
| |
| RFC 9098 | Operational Implications of IPv6 Packets with Extension Headers |
| |
| Authors: | F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu. |
| Date: | September 2021 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9098 |
|
This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. |
|
| |
| RFC 9099 | Operational Security Considerations for IPv6 Networks |
| |
| Authors: | É. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9099 |
|
Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks. |
|
