Recent RFCsRecently published RFCs2024-03-21T00:37:07-07:00RFC Editorhttps://www.rfc-editor.orgRFC 9499: DNS Terminologyhttps://www.rfc-editor.org/info/rfc94992024-03-21T00:00:00-07:00The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has changed in the
decades since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single
document.
This document updates RFC 2308 by clarifying the definitions of
"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple
terms and clarifications. Comprehensive lists of changed and new
definitions can be found in Appendices A and B.RFC 9528: Ephemeral Diffie-Hellman Over COSE (EDHOC)https://www.rfc-editor.org/info/rfc95282024-03-20T00:00:00-07:00This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
very compact and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication,
forward secrecy, and identity protection. EDHOC is intended for usage
in constrained scenarios, and a main use case is to establish an
Object Security for Constrained RESTful Environments (OSCORE)
security context. By reusing CBOR Object Signing and Encryption
(COSE) for cryptography, Concise Binary Object Representation (CBOR)
for encoding, and Constrained Application Protocol (CoAP) for
transport, the additional code size can be kept very low.RFC 9529: Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC)https://www.rfc-editor.org/info/rfc95292024-03-20T00:00:00-07:00This document contains example traces of Ephemeral Diffie-Hellman
Over COSE (EDHOC).RFC 9509: X.509 Certificate Extended Key Usage (EKU) for 5G Network Functionshttps://www.rfc-editor.org/info/rfc95092024-03-20T00:00:00-07:00RFC 5280 specifies several extended key purpose identifiers
(KeyPurposeIds) for X.509 certificates. This document defines
encrypting JSON objects in HTTP messages, using JSON Web Tokens
(JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for
inclusion in the Extended Key Usage (EKU) extension of X.509 v3
public key certificates used by Network Functions (NFs) for the 5G
System.RFC 9541: Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)https://www.rfc-editor.org/info/rfc95412024-03-20T00:00:00-07:00Provider Backbone Bridging (PBB) can be combined with Ethernet
Virtual Private Networks (EVPNs) to deploy Ethernet Local Area
Network (E-LAN) services in large Multiprotocol Label Switching
(MPLS) networks. That combination is what we refer to as "PBB-EVPN."
Single-Active multihoming and per Service Instance Identifier (I-SID)
load-balancing can be provided to access devices and aggregation
networks. In order to speed up the network convergence in case of
failures on Single-Active multihomed Ethernet Segments (ESs),
PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called
"C-MAC flush" that works for different Ethernet Segment Backbone MAC
(B-MAC) address allocation models. This document complements those
C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined
(i.e., the attachment circuit is associated with a zero Ethernet
Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level
granularity.RFC 9544: Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)https://www.rfc-editor.org/info/rfc95442024-03-20T00:00:00-07:00This document defines a set of metrics for networking services with
performance requirements expressed as Service Level Objectives
(SLOs). These metrics, referred to as "Precision Availability Metrics
(PAMs)", are useful for defining and monitoring SLOs. For example,
PAMs can be used by providers and/or customers of an RFC 9543 Network
Slice Service to assess whether the service is provided in compliance
with its defined SLOs.RFC 9550: Deterministic Networking (DetNet): Packet Ordering Functionhttps://www.rfc-editor.org/info/rfc95502024-03-20T00:00:00-07:00The replication and elimination functions of the Deterministic
Networking (DetNet) architecture can result in out-of-order packets,
which is not acceptable for some time-sensitive applications. The
Packet Ordering Function (POF) algorithms described in this document
enable restoration of the correct packet order when the replication
and elimination functions are used in DetNet networks. The POF only
provides ordering within the latency bound of a DetNet flow; it does
not provide any additional reliability.RFC 9508: Information-Centric Networking (ICN) Ping Protocol Specificationhttps://www.rfc-editor.org/info/rfc95082024-03-11T00:00:00-07:00This document presents the design of an Information-Centric
Networking (ICN) Ping protocol. It includes the operations of both
the client and the forwarder.
This document is a product of the Information-Centric Networking
Research Group (ICNRG) of the IRTF.RFC 9507: Information-Centric Networking (ICN) Traceroute Protocol Specificationhttps://www.rfc-editor.org/info/rfc95072024-03-11T00:00:00-07:00This document presents the design of an Information-Centric
Networking (ICN) Traceroute protocol. This includes the operation of
both the client and the forwarder.
This document is a product of the Information-Centric Networking
Research Group (ICNRG) of the IRTF.RFC 9531: Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)https://www.rfc-editor.org/info/rfc95312024-03-11T00:00:00-07:00Path steering is a mechanism to discover paths to the producers of
Information-Centric Networking (ICN) Content Objects and steer
subsequent Interest messages along a previously discovered path. It
has various uses, including the operation of state-of-the-art
multi-path congestion control algorithms and for network measurement
and management. This specification derives directly from the design
published in "Path Switching in Content Centric and Named Data
Networks" (4th ACM Conference on Information-Centric Networking) and,
therefore, does not recapitulate the design motivations,
implementation details, or evaluation of the scheme. However, some
technical details are different, and where there are differences, the
design documented here is to be considered definitive.
This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). It is not an IETF product and is not an
Internet Standard.RFC 9543: A Framework for Network Slices in Networks Built from IETF Technologieshttps://www.rfc-editor.org/info/rfc95432024-03-11T00:00:00-07:00This document describes network slicing in the context of networks
built from IETF technologies. It defines the term "IETF Network
Slice" to describe this type of network slice and establishes the
general principles of network slicing in the IETF context.
The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network
Slice, the necessary system components and interfaces, and the
mapping of abstract requests to more specific technologies. The
document also discusses related considerations with monitoring and
security.
This document also provides definitions of related terms to enable
consistent usage in other IETF documents that describe or use aspects
of IETF Network Slices.RFC 9551: Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)https://www.rfc-editor.org/info/rfc95512024-03-11T00:00:00-07:00Deterministic Networking (DetNet), as defined in RFC 8655, aims to
provide bounded end-to-end latency on top of the network
infrastructure, comprising both Layer 2 bridged and Layer 3 routed
segments. This document's primary purpose is to detail the specific
requirements of the Operations, Administration, and Maintenance (OAM)
recommended to maintain a deterministic network. The document will be
used in future work that defines the applicability of and extension
of OAM protocols for a deterministic network. With the
implementation of the OAM framework in DetNet, an operator will have
a real-time view of the network infrastructure regarding the
network's ability to respect the Service Level Objective (SLO), such
as packet delay, delay variation, and packet-loss ratio, assigned to
each DetNet flow.RFC 9549: Internationalization Updates to RFC 5280https://www.rfc-editor.org/info/rfc95492024-03-11T00:00:00-07:00The updates to RFC 5280 described in this document provide alignment
with the 2008 specification for Internationalized Domain Names (IDNs)
and includes support for internationalized email addresses in X.509
certificates. The updates ensure that name constraints for email
addresses that contain only ASCII characters and internationalized
email addresses are handled in the same manner. This document
obsoletes RFC 8399.RFC 9565: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Elementhttps://www.rfc-editor.org/info/rfc95652024-03-11T00:00:00-07:00RFC 7125 revised the tcpControlBits IP Flow Information Export
(IPFIX) Information Element that was originally defined in RFC 5102
to reflect changes to the TCP header control bits since RFC 793.
However, that update is still problematic for interoperability
because some flag values have subsequently been deprecated.
This document removes stale information from the IANA "IPFIX
Information Elements" registry and avoids future conflicts with the
authoritative IANA "TCP Header Flags" registry.
This document obsoletes RFC 7125.RFC 9539: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNShttps://www.rfc-editor.org/info/rfc95392024-02-28T00:00:00-08:00This document sets out steps that DNS servers (recursive resolvers
and authoritative servers) can take unilaterally (without any
coordination with other peers) to defend DNS query privacy against a
passive network monitor. The protections provided by the guidance in
this document can be defeated by an active attacker, but they should
be simpler and less risky to deploy than more powerful defenses.
The goal of this document is to simplify and speed up deployment of
opportunistic encrypted transport in the recursive-to-authoritative
hop of the DNS ecosystem. Wider easy deployment of the underlying
encrypted transport on an opportunistic basis may facilitate the
future specification of stronger cryptographic protections against
more-powerful attacks.