| |
|
| |
| | Mobility aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-09.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G supports logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G services, user's data plane packets over the radio access network (RAN) and mobile core network (5GC) use IP transport in many segments of the end-to-end 5G slice. When end-to- end slices in a 5G system use IP network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation and other criteria requested by the 5G slice. This document describes mapping of 5G slices to IP or Layer 2 transport network slices when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping proposed here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | IP Fragmentation Avoidance in DNS over UDP |
| |
|
The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document specifies techniques to avoid IP fragmentation in DNS. |
| | A YANG Data Model for In-Situ OAM |
| |
| | draft-ietf-ippm-ioam-yang-13.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Tianran Zhou, Jim Guichard, Frank Brockners, Srihari Raghavan |
| | Working Group: |
IP Performance Measurement (ippm) |
|
In-situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method to produce operational and telemetry information that may be exported using the in-band or out-of-band method. RFC9197 and RFC9326 discuss the data fields and associated data types for IOAM. This document defines a YANG module for the configuration of IOAM functions. |
| | YANG Data Model for IS-IS SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. |
| | Randomized and Changing MAC Address Use Cases |
| |
| | draft-ietf-madinas-use-cases-09.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Jerome Henry, Yiu Lee |
| | Working Group: |
MAC Address Device Identification for Network and Application Services (madinas) |
|
To limit the privacy issues created by the association between a device, its traffic, its location and its user, client and client OS vendors have started implementing MAC address rotation. When such a rotation happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC rotation purposes. This document lists various network environments and a set of network services that may be affected by such rotation. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. |
| | Multicast YANG Data Model |
| |
|
This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. |
| | YANG Data Model for MPLS mLDP |
| |
| | draft-ietf-mpls-mldp-yang-11.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the "charset" that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines "Modern Network Unicode" (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | Antitrust Guidelines for IETF Participants |
| |
|
This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. |
| | RIFT Auto-Flood Reflection |
| |
|
This document specifies procedures where RIFT can automatically provision IS-IS Flood Reflection topologies by leveraging its native no-touch ZTP architecture. |
| | PCEP for Enhanced DetNet |
| |
|
PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane. |
| | Compressed SID (C-SID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming. |
| | Managing CBOR numbers in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal "e", a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | SR Policy for enhanced DetNet |
| |
|
SR Policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied. |
| | IETF Meeting Venue Requirements Review |
| |
|
Following a review of the IETF meeting venue requirements, this document proposes updates to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and proposes a replacement exploratory meeting process, thereby updating RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF". |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the framework and the operational procedure for deterministic networking with work conserving packet schedulers that guarantee end-to-end latency bounds to flows. Schedulers in core nodes of the network do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding a delay factor, which is a function of the flow and upstream nodes. The packets in the queue are served in the ascending order of the FT. This technique is called Fair Queuing (FQ). The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters, except the link capacities and the maximum packet lengths among other flows sharing each output link with the flow. |
| | HPCC++: Enhanced High Precision Congestion Control |
| |
| | draft-miao-ccwg-hpcc-02.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman |
| | Working Group: |
Individual Submissions (none) |
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. |
| | Inband Telemetry for HPCC++ |
| |
| | draft-miao-ccwg-hpcc-info-02.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman |
| | Working Group: |
Individual Submissions (none) |
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. |
| | Associated Gateway Exchange in Multi-segment SD-WAN |
| |
|
The document describes the control plane enhancement for multi- segment SD-WAN to exchange the associated GW information between edges. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (idr@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/idr/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-sheng-idr-gw-exchange-in-sd-wan. |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/shuque/ietf-dns-grease. |
| | Intelligent Protection Optimization System for IOT |
| |
|
Communication technology is becoming more and more developed, the Internet of Things coverage is becoming more and more comprehensive, and a large number of data and devices are joining, which also makes more data security and privacy issues appear. Therefore, this draft proposes a scheme to build an information-centered network. By analyzing common network attack methods, an intelligent protection optimization system is established from three aspects: naming and parsing, data exchange, and data caching, so as to achieve better content privacy protection without adding additional costs. |
| | BGP AS_PATH Validation State Extended Community |
| |
|
This document defines a new BGP opaque extended community to carry the AS_PATH validation state based on Autonomous System Provider Authorization (ASPA) inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process. |
| | Destination-IP-Community Filter for BGP Flow Specification |
| |
|
BGP Flowspec mechanism (BGP-FS) propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support community-level filtering. The match field is the community of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. |
| | External References to Values in CBOR Diagnostic Notation (EDN) |
| |
|
The Concise Binary Object Representation (CBOR, 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. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While their role in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. While the goals of the description are similar to that used in previous specficaion, the approach taken is substantally different, in that a core set of functionality, derived form the the now- withdrawn POSIX draft ACLs is the conceptual base of the feature set while extensions to that functionality are made available as OPTIONAL extensions to that core. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents such as RFCs 7530 and 8881, thereby updating RFC7530 and RFC8881. |
| | Latency analysis of mobile transmission |
| |
|
Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. |
| | Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | BGP-MVPN Source Active Route Enhancement |
| |
|
RFC6514 specifies the protocol and procedures for multicast in MPLS/ BGP IP VPNs. In the Any-Source Multicast (ASM) case, the section "14. Supporting PIM-SM without Inter-Site Shared C-Trees" specifies that the Provider Edge that serves as a customer Rendezvous Point or runs Multicast Source Discovery Protocol advertises Source Active (SA) routes for ASM flows when it discovers those flows. This document describes a situation where an optional enhancement to the advertisement of SA routes is desired and specifies the procedures. It updates RFC6514. |
| | Triggering Unsolicited Router Advertisements Upon Configuration Changes |
| |
|
IPv6 routers employ Router Advertisements (RAs) to disseminate essential network configuration data to hosts. RAs play a vital role in Stateless address autoconfiguration (SLAAC) and providing IPv6 connectivity. Timely updates via RAs become paramount as network configurations change to prevent service outages. This document modifies RFC4861, recommending immediate propagation of configuration information changes by routers. |
| | Customer Experience Index for Evaluating Network Quality for Cloud Applications |
| |
| | draft-hz-ippm-cei-00.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Hongyi Huang, Tianran Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network. |
| | The OID Directory: A Technical Roadmap |
| |
|
This ID outlines a series of experimental standards documents which define the abstracts of the "OID Directory": a proposed philosophy and set of procedures used to facilitate the storage and management of the "OID spectrum" -- in part or in whole -- within an X.500/LDAP service implementation. |
| | The OID Directory: The Schema |
| |
|
In service to the "OID Directory" ID series, this ID declares schema definitions for use within an implementation of the Registration Authority Directory Information Tree. See the RADIR ID for a complete draft series manifest. |
| | The OID Directory: The RA DUA |
| |
|
In service to the "OID Directory" ID series, this ID covers design strategies, requirements and procedures for the client component of the OID Directory Registration Authority client/server model. See the RADIR ID for a complete draft series manifest. |
| | The OID Directory: The RA DSA |
| |
|
In service to the "OID Directory" ID series, this ID covers design considerations and basic requirements for the server component of the OID Directory Registration Authority client/server model. See the RADIR ID for a complete draft series manifest. |
| | The OID Directory: The RA DIT |
| |
|
In service to the "OID Directory" ID series, this ID covers design strategies and requirements relating to the Registration Authority Directory Information Tree. See the RADIR ID for a complete draft series manifest. |
| | Deterministic Routing Header |
| |
|
This document introduces a new IPv6 Routing Header used for deterministic forwarding wihch is generally a strict explicit path. This Routing Header will contain the decoupled topology instructions and deterministic forwarding resource indications. The target is low cost of encapasultion and less amount of allocated SIDs. |
| | Anomalous Packets Handling for DetNet |
| |
|
In deterministic networking (DetNet), there may be resource conflicts at the flow aggregation nodes, resulting in network anomalies. The existing mechanisms for handling anomalous packets in the data plane are crude, such as discarding or processing them as BE flows, so the network performance may be worse than applying traditional QoS. Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an anomalous packet handling solution for anomalous traffic in DetNet. This solution includes two policies: the packet squeezing policy and the packet degrading policy, which can be applied flexibly to a variety of queuing mechanisms, thereby ensuring that network traffic for deterministic services is preferentially scheduled in anomalous situations. |
| | Gap Analysis of Online Data Express Service (ODES) |
| |
|
This document is a gap analysis of online data express delivery services, which is helpful to the design and development of online data express delivery services. |
| | Trust-enhanced Path Routing: Problem Statement and Use Cases |
| |
|
Digital trust refers to the measurable confidence of one entity posts on another about accomplishing some task in the digital world. This document introduces the concept of trust into the networking and routing area, and proposes the idea of trust-enhanced path routing, elaborates the key technical problems and design goals, and also lists some use cases. |
| | Distributed Aggregation Protocol for Privacy Preserving Measurement |
| |
| | draft-ietf-ppm-dap-10.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Tim Geoghegan, Christopher Patton, Brandon Pitman, Eric Rescorla, Christopher Wood |
| | Working Group: |
Privacy Preserving Measurement (ppm) |
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. |
| | RADIUS and TLS-PSK |
| |
|
This document gives implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the insecure RADIUS/UDP to the use of the much more secure RADIUS/TLS. |
| | RIFT Auto-EVPN |
| |
|
This document specifies procedures that allow an EVPN overlay to be fully and automatically provisioned when using RIFT as underlay by leveraging RIFT's no-touch ZTP architecture. |
| | BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects |
| |
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This type of AS_PATH verification provides detection and mitigation of route leaks and improbable AS paths. It also provides protection, to some degree, against prefix hijacks with forged-origin or forged-path-segment. |
| | Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) |
| |
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. |
| | TVR (Time-Variant Routing) Use Cases |
| |
| | draft-ietf-tvr-use-cases-09.txt |
| | Date: |
29/02/2024 |
| | Authors: |
Edward Birrane, Nicolas Kuhn, Yingzhen Qu, Rick Taylor, Li Zhang |
| | Working Group: |
Time-Variant Routing (tvr) |
|
This document introduces use cases where Time-Variant Routing (TVR) computations (i.e. routing computations taking into considerations time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance. |
| |
|
| |
| | Transmission of SCHC-compressed packets over IEEE 802.15.4 networks |
| |
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. |
| | Semantic Definition Format (SDF) for Data and Interactions of Things |
| |
| | draft-ietf-asdf-sdf-18.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Michael Koster, Carsten Bormann, Ari Keranen |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. // The present revision (-18) adds security considerations, a few // editorial cleanups, discusses JSON pointer encodings, and adds // sockets to the CDDL for easier future extension. |
| | EVPN Virtual Ethernet Segment |
| |
|
Etheret VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a family of solutions for Ethernet services over MPLS/IP network with many advanced features including multi-homing capabilities. These solutions introduce Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of Ethernet Virtual Circuits (EVCs e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs). Such an ES is referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. |
| | A YANG Data Model for Microwave Topology |
| |
| | draft-ietf-ccamp-mw-topo-yang-12.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Scott Mansfield, Jonas Ahlberg, Min Ye, Xi Li, Daniela Spreafico |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model to describe microwave/ millimeter radio links in a network topology. |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) |
| |
| | draft-ietf-dmarc-dmarcbis-30.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Todd Herr, John Levine |
| | Working Group: |
Domain-based Message Authentication, Reporting & Conformance (dmarc) |
|
This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. |
| | DMARC Aggregate Reporting |
| |
|
DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes [RFC7489]. |
| | Fully-Specified Algorithms for JOSE and COSE |
| |
|
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for all registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. |
| | Randomized and Changing MAC Address state of affairs |
| |
|
Users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on MAC addresses. There have been several initiatives within the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities to help coordinating standardization activities in these bodies. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | Constrained Application Protocol (CoAP): Corrections and Clarifications |
| |
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. |
| | Unicast Use of the Formerly Special-Cased 127/8 |
| |
|
This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. |
| | PCEP Extension for Bounded Latency |
| |
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. |
| | DAP Interoperation Test Design |
| |
|
This document defines a common test interface for implementations of the Distributed Aggregation Protocol for Privacy Preserving Measurement (DAP) and describes how this test interface can be used to perform interoperation testing between the implementations. Tests are orchestrated with containers, and new test-only APIs are introduced to provision DAP tasks and initiate processing. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | QUIC Address Discovery |
| |
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. |
| | CATS based on Real Locator |
| |
|
This document describes a solution framework that adheres to the CATS framework. The solution uses anycast IP addresses as the CATS service identifier and real locator of the service contact instance as the CATS Instance Selection ID. |
| | Application Aware Computing Network |
| |
|
This document describes a solution framework that adheres to the CATS framework. The solution uses APN as part of the CATS service identifier and flow identifier. |
| | 464 Customer-side Translator (CLAT): Node Recommendations |
| |
|
464XLAT ([RFC6877]) defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document provides recommendations on when a node shall enable or disable CLAT. |
| | An In Situ Operations,Administration,and Maintenance (IOAM) Multi-path Flag |
| |
|
Active measurements are typically used to collect the information of a specific path. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which can promote the information collection and topology restoration of a multi-path topology. |
| | RoCEv2-based Collective Communication Offloading |
| |
| | draft-liu-nfsv4-rocev2-00.txt |
| | Date: |
28/02/2024 |
| | Authors: |
liufeng, Weifeng Wang, Rubing Liu, Yan Mu, Kehan Yao |
| | Working Group: |
Individual Submissions (none) |
|
This draft proposes the design scheme of RoCEv2-based collective communication offloading. Through establishing RDMA connections between client and switch, collective operations can be implemented on network nodes, thus improving the overall efficiency of collective communication. |
| | IP Payload Compression excluding transport layer |
| |
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. |
| | Secure shell over HTTP/3 connections |
| |
| | draft-michel-ssh3-00.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Francois Michel, Olivier Bonaventure |
| | Working Group: |
Individual Submissions (none) |
|
The secure shell (SSH) traditionally offers its secure services over an insecure network using the TCP transport protocol. This document defines mechanisms to run the SSH protocol over HTTP/3 using Extended CONNECT. Running SSH over HTTP/3 enables additional benefits such as the scalability offered by HTTP multiplexing, relying on TLS for secure channel establishment leveraging X.509 certificates, HTTP Authentication schemes for client and server authentication, UDP port forwarding and stronger resilience against packet injection attacks and middlebox interference. |
| | Problem Statement with Aggregate Header Limit |
| |
|
Aggregate header limit(AHL) is the total header size that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. This document describes the problems for path calculation and function enablement without the awareness of AHL in SRv6, and the considerations for AHL collection are also included. |
| | Implementation and Performance Evaluation of PDM using eBPF |
| |
| | draft-ne-v6ops-pdm-ebpf-00.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Nalini Elkins, Chinmaya Sharma, Amogh Umesh, Balajinaidu V, Mohit Tahiliani |
| | Working Group: |
Individual Submissions (none) |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. |
| | A SAVI Solution for IP based Satellite Access |
| |
| | draft-jliu-savi-ipsa-00.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Jun Liu, Hewu Li, Tianyu Zhang, Qian Wu |
| | Working Group: |
Individual Submissions (none) |
|
This document presents the source address validation solution for for IP based Satellite Access. This mechanism transfers user states through end network collaboration to solve the impact of dynamic handover of satellite-ground links on native SAVI. This document mainly describes the operations involved in overcoming the dynamics of the access link. |
| | Segment Routing over IPv6 (SRv6) Proof of Transit |
| |
|
Various technologies, including SRv6, allow to perform Traffic Engineering (TE), steering IP traffic through a specific path. However, there is no native mechanism in IP that allows to verify whether or not a packet did follow the path it was supposed to. This document specifies a new TLV for the Segment Routing Header (SRH) that allows to provide a cryptographically generated proof of transit over the different segments. The proposed mechanisms allows to verify whether a packet did go through the segments listed in its SRH header in the intended order. |
| | A Path Verification Solution based on SRv6 |
| |
| | draft-jliu-tpp-srv6-00.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Jun Liu, Hewu Li, Tianyu Zhang, Qian Wu, Zongpeng Du |
| | Working Group: |
Individual Submissions (none) |
|
A trusted network path is desired for source authentication and path verification. The emergence of IPv6 Segment Routing (SRv6) may bring the opportunity to assemble trusted network paths with a lightweight IP header. This document describes a trusted network path verification mechanism based on SRv6 (Segment Routing to enable Trusted and Private Network Paths, SR-TPP), which supports network path verification with path information protection. SR-TPP extends SRv6 function in protocol header to meet the requirement of path compliance. Path information is sequentially encoded into the segment list in SR-TPP so that path information is partially visible to each intermediate router. The distributed verification of SR-TPP also makes it easier to locate faults. |
| | ML-KEM for HPKE |
| |
|
This memo defines the ML-KEM-768-based and ML-KEM-1024-based ciphersuites for HPKE (RFC9180). ML-KEM is believed to be secure even against adversaries who possess a quantum computer. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | OAuth 2.0 for Browser-Based Apps |
| |
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. |
| | QUIC Stream Resets with Partial Delivery |
| |
|
QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. |
| | Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) |
| |
|
The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP includes guidance concerning those deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency. |
| | A YANG Data Model for Resource Reservation Protocol (RSVP) |
| |
| | draft-ietf-teas-yang-rsvp-19.txt |
| | Date: |
28/02/2024 |
| | Authors: |
Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names |
| |
|
The document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor hidden services (".onion" Special-Use Domain Names). Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/AS207960/acme-onion. The project website and a reference implementation can be found at https://acmeforonions.org. |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-04.txt |
| | Date: |
27/02/2024 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Compression Dictionary Transport |
| |
|
This specification defines a mechanism for using designated HTTP responses as an external dictionary for future HTTP responses for compression schemes that support using external dictionaries (e.g., Brotli (RFC 7932) and Zstandard (RFC 8878)). |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules to support the configuration of UDP clients and UDP servers. |
| | SRv6 Deployment Consideration |
| |
|
SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced. |
| | Remove SHA-1 from active use within DNSSEC |
| |
|
This document retires the use of SHA-1 within DNSSEC. |
| | DNSSEC Cryptographic Algorithms |
| |
|
[EDITOR NOTE: This document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in [RFC8624]; that is the work of future documents. Instead, this document moves the canonical list of algorithms from [RFC8624] to an IANA registry. This is done for two reasons: 1) to allow the list to be updated more easily, and, much more importantly, 2) to allow the list to be more easily referenced.] The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs. |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610 and RFC 9165. The latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0". It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. It is intended to serve as a basis for prototypical implementations of CDDL 2.0. This document is intended to evolve over time; it might spawn specific documents and then retire or eventually be published as a roadmap document. |
| | CDDL models for some existing RFCs |
| |
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. |
| | Using ALTO for exposing Time-Variant Routing information |
| |
|
Network operations can require time-based, scheduled changes in nodes, links, adjacencies, etc. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can assist, as an off-path mechanism, on the exposure of such predicted changes to both internal and external applications then anticipating the occurrence of routing changes. This document describes how ALTO helps in that purpose. |
| | IGP Color-Aware Shortcut |
| |
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document describes the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. |
| | WebSocket Extension to disable masking |
| |
|
The WebSocket protocol specifies that all frames sent from the client to the server must be masked. This was introduced as a protection against a possible attack on the infrastructure. With careful consideration, the masking could be omitted when intermediaries do not have access to the unencrypted traffic. This specification introduces a WebSocket extension that disables the mandatory masking of frames sent from the client to the server. The extension is allowed only if the client uses an encrypted connection. |
| | Requirements from Control and Management Viewpoint for Collective Communication Optimization |
| |
|
Collective communication optimization is crucial to improve the performance of distributed applications, due to that communication has become bottleneck to degrade applications with the growth of scale of distributed systems. The industry and academy has worked on proposing solutions to upgrade collective communication operations. However, there has been a problem of lacking for unified guidelines. This draft provide requirements on collective communication optimization from the control and management viewpoint. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Remove ECC-GOST from active use within DNSSEC |
| |
|
This document retires the use of ECC-GOST within DNSSEC. |
| | A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs |
| |
| | draft-ietf-rats-yang-tpm-charra-22.txt |
| | Date: |
27/02/2024 |
| | Authors: |
Henk Birkholz, Michael Eckel, Shwetha Bhandari, Eric Voit, Bill Sulzen, Liang Xia, Tom Laffey, Guy Fedorkow |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines YANG Remote Procedure Calls (RPCs) and a few configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), or equivalent hardware implementations that include the protected capabilities as provided by TPMs as well as a corresponding software stack, included in the device components of the composite device the YANG server is running on. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-04.txt |
| | Date: |
27/02/2024 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines the RATS conceptual message wrapper (CMW) format, a type of encapsulation format that can be used for any RATS messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. Additionally, the document describes a collection type that enables the aggregation of one or more CMWs into a single message. This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. |
| | Versioning in the Registration Data Access Protocol (RDAP) |
| |
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. |
| | An RDAP With Extensions Media Type |
| |
|
This document defines a media type for RDAP that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this media type with RDAP. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| |
|
| |
| | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| | draft-ietf-dhc-rfc8415bis-04.txt |
| | Date: |
26/02/2024 |
| | Authors: |
Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
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). This document replaces RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). |
| | Simple Mail Transfer Protocol |
| |
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. |
| | Group Key Management using IKEv2 |
| |
|
This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE". |
| | BGP Extensions of SR Policy for Composite Candidate Path |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. |
| | Signaling Composite Candidate Path of SR Policy using BGP-LS |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. |
| | Enhanced DetNet Data Plane Framework for Scaling Deterministic Networks |
| |
|
The Enhanced Deterministic Networking (EDN) is required to provide the enhancement of flow identification and packet treatment for Deterministic Networking (DetNet) to achieve the DetNet QoS in scaling networks. This document proposes the enhancement of the framework to support the functions and metadata for enhanced DetNet data plane. |
| | TCP RST Diagnostic Payload |
| |
|
This document specifies a diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. |
| | Extension Header Use Cases |
| |
|
This document outlines IPv6 extension header use cases including those intended to be deployed in limited domains and those intended for the global Internet. We specify use cases are deployed today and those which may be of use in the future. The hope is that through understanding these various extension header use cases, we can then better understand how best to improve upon extension header deployments including any limits on their use. |
| | BBS for PrivacyPass |
| |
|
Existing token types in privacy pass conflate attribution with rate limiting. This document describes a token type where the issuer attests to a set of properties of the client, which the client can then selectively prove to the origin. Repeated showings of the same credential are unlinkable, unlike other token types in privacy pass. |
| | Retiring the Tao of the IETF |
| |
|
This document retires and obsoletes the Tao of the IETF as an IETF- maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included as an annex. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way. |
| | Terminology and Use cases for Secured Routing Infrastructure |
| |
|
This document collects terminology and use cases for Secured Routing. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | Terminal Identity Authentication Based on Address Label |
| |
|
Privacy and accountability are currently significant concerns on the internet. Privacy generally implies untraceable sources. Effective verification methods inherently raise privacy concerns when confirming a user's identity. To prevent extensive modifications to current network protocols and the introduction of new identifiers, we propose an IPv6 based address label terminal identity authentication mechanism. This mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document outlines the implementation of address label authentication in the IPv6 extension header. |
| | Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. |
| | PCEP extensions for Circuit Style Policies |
| |
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. |
| | PIM Join/ Prune Attributes for LISP Environments using Underlay Multicast |
| |
|
This document specifies an update to the PIM Receiver RLOC Join/ Prune attribute that supports the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). |
| | PIM Light |
| |
| | draft-ietf-pim-light-02.txt |
| | Date: |
26/02/2024 |
| | Authors: |
Hooman Bidgoli, Stig Venaas, Mankamana Mishra, Zhaohui Zhang, Mike McBride |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document specifies a new Protocol Independent Multicast interface which does not need PIM Hello to accept PIM Join/Prunes. |
| | RADIUS ALPN and removing MD5 |
| |
|
This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an additional application protocol for RADIUS over (D)TLS. No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are removed. When this extension is used, the previous Authenticator field is repurposed to contain an explicit request / response identifier, called a Token. The Token also allows more than 256 packets to be outstanding on one connection. This extension can be seen as a transport profile for RADIUS, as it is not an entirely new protocol. It uses the existing RADIUS packet layout and attribute format without change. As such, it can carry all present and future RADIUS attributes. Implementation of this extension requires only minor changes to the protocol encoder and decoder functionality. The protocol defined by this extension is named "RADIUS version 1.1", or "RADIUS/1.1". |
| |
|
| |
| | HTTP Link Hints |
| |
|
This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. |
| | MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
| |
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-06.txt |
| | Date: |
25/02/2024 |
| | Authors: |
Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid |
| | Working Group: |
IP Performance Measurement (ippm) |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. |
| | Remote APDU Call Secure (RACS) |
| |
|
This document describes the Remote APDU Call Protocol Secure (RACS) protocol, dedicated to Grid of Secure Elements (GoSE). These servers host Secure Elements (SE), i.e. tamper resistant chips offering secure storage and cryptographic resources. Secure Elements are microcontrollers whose chip area is about 25mm2; they deliver trusted computing services in constrained environments. RACS supports commands for GoSE inventory and data exchange with secure elements. It is designed according to the representational State Transfer (REST) architecture. RACS resources are identified by dedicated URIs. An HTTP interface is also supported. An open implementation [OPENRACS] is available (https://github.com/purien) for various OS. |
| | Internet of Secure Elements |
| |
|
This draft defines an infrastructure for secure elements over internet, and features needed for their secure remote use. It describes a network architecture based on the TLS 1.3 protocol, which enables remote calls of cryptographic procedures, identified by Unified Resource Identifier (URI) such as schemeS://sen@server.com:443/?query The Internet of Secure Element (IoSE) is a set of secure elements providing TLS servers, communication interfaces, and identified by their name (Secure Element Name, sen). |
| | TLS for Secure Element Input Output (TLS-SE-IO) |
| |
|
The goal of TLS-SE-IO is to provide virtual IO pins for secure elements running TLS servers, in order to interact with sensors and actuators. TLS-SE device processes TLS packets in secure element. It may work like a black box (server mode) that exchanges fully encrypted packets. It may also export encrypted packet in clear form, in order to provide virtual output pin. Output messages may include cookies and/or cryptographic materials. Virtual input pin forwards input messages, triggered by previous output messages, and sent to TLS-SE device for further processing. |
| | BIER Extension Headers |
| |
|
Bit Index Explicit Replication (BIER) is a multicast technology with a new encapsulation and forwarding paradigm. BIER encapsulation is specified in RFC8296, and this document specifies extension headers used with BIER encapsulation header. |
| | Gap Analysis for Enhanced DetNet |
| |
|
From charter and milestones, the enhanced Deterministic Networking (DetNet) is required to provide the enhancement of flow identification and packet treatment for data plane to achieve the DetNet QoS in large-scale networks. This document discusses the characteristics of scaling deterministic networks and analyzes the gaps of the existing technologies especially applying the DetNet data plane as per RFC8938. |
| | The eap.arpa domain and EAP provisioning |
| |
|
This document defines the eap.arpa domain as a way for EAP peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers leverage user identifier portion of the Network Access Identifier (NAI) format of RFC7542 in order to describe what kind of provisioning they need. A table of identifiers and meanings is defined. |
| | Using Subnet-Specific Link-Local Addresses to Improve SLAAC Robustness |
| |
|
This document suggests that a link-local address used by a router as a source address for Router Advertisement packets is calculated as a function of prefixes listed in the Prefix Information Option of the Router Advertisement. The proposed approach, combined with the Rule 5.5 of the Default Source Address Selection algorithm (RFC6724) and first-hop selection requirements for hosts (RFC 8028) improves the robustness of the SLAAC by allowing the hosts to detect the IPv6 subnet changes much faster and select the correct source address. |
| | Fully Adaptive Routing Ethernet |
| |
| | draft-xu-lsr-fare-02.txt |
| | Date: |
25/02/2024 |
| | Authors: |
Xiaohu Xu, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Shraddha Hegde |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource- intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three- stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically load balance traffic to the same destination over multiple ECMP paths, based on network capacity and even congestion information along those paths. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | Intra-domain SAV Support via IGP |
| |
|
This document describes a Dynamic calculation SAVNET mechanism by extending IGP protocol in intra-domain scenarios. This mechanism can propagate SAV-related information through IGP messages to help routers automatically generate accurate SAV rules which are for checking the validity of data packets. |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also briefly mentioned. |
| | Advertisement of SR Policy Flexible Candidate Path Selection Result using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the result of SR Policy flexible candidate path selection. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. |
| | Addition of New BMP Stat Types |
| |
|
BMP statistics messages are used by the monitoring station to observe interesting events that occur on the router. Several BMP statistics types are defined in RFC 7854, this document lists some new statistics types to update RFC 7854 for growing BGP features. |
| | Policy Considerations for Changes to RFCs |
| |
|
This document clarifies the policy framework for changes to RFC formats and associated tool chains. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-rswg-format- details/. Discussion of this document takes place on the RSWG Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. |
| | Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions |
| |
|
Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. |
| |
|
| |
| | Common YANG Data Types for Layer 1 Networks |
| |
|
This document defines a collection of common common data types, identities, and groupings in the YANG data modeling language. These derived common common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. |
| | Use Cases for In-Network Computing |
| |
| | draft-irtf-coinrg-use-cases-05.txt |
| | Date: |
23/02/2024 |
| | Authors: |
Ike Kunze, Klaus Wehrle, Dirk Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio |
| | Working Group: |
Computing in the Network Research Group (coinrg) |
|
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it further identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. It is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard. |
| | Deterministic Networking (DetNet) YANG Model |
| |
| | draft-ietf-detnet-yang-20.txt |
| | Date: |
23/02/2024 |
| | Authors: |
Xuesong Geng, Yeoncheol Ryoo, Don Fedyk, Reshad Rahman, Zhenqiang Li |
| | Working Group: |
Deterministic Networking (detnet) |
|
This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data of DetNet Flows. The model allows for provisioning of end-to-end DetNet service on devices along the path without dependency on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | IAB Barriers to Internet Access of Services (BIAS) Workshop Report |
| |
|
The “Barriers for Internet Access of Services (Bias)” workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role of community networks in Internet Access of Services; reports and comments on the observed digital divide; and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussion and serves as a reference for reports on the current barriers to Internet Access. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. |
| | Updates to Anycast Property advertisement for OSPFv2 |
| |
| | draft-chen-lsr-anycast-flag-06.txt |
| | Date: |
23/02/2024 |
| | Authors: |
Ran Chen, Detao Zhao, Peter Psenak, Ketan Talaulikar, Changwang Lin |
| | Working Group: |
Individual Submissions (none) |
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | Mobile User Plane Evolution |
| |
| | draft-zzhang-dmm-mup-evolution-08.txt |
| | Date: |
23/02/2024 |
| | Authors: |
Zhaohui Zhang, Keyur Patel, Luis Contreras, Kashif Islam, Jari Mutikainen, Tianji Jiang, Luay Jalil, Ori Sejati, Shay Zadok |
| | Working Group: |
Individual Submissions (none) |
|
This document describes evolution of mobile user plane in 5G, including distributed User Plane Functions (UPFs) and alternative user plane implementations that some vendors/operators are promoting without changing 3GPP architecture/signaling, and further discusses potentially integrating UPF and Access Node (AN) in 6G mobile networks. This document is not an attempt to do 3GPP work in IETF. Rather, it discusses potential integration of IETF/wireline and 3GPP/wireless technologies - first among parties who are familiar with both areas and friendly with IETF/wireline technologies. If the ideas in this document are deemed reasonable, feasible and desired among these parties, they can then be brought to 3GPP for further discussions. |
| | Compact ECDHE and ECDSA Encodings for TLS 1.3 |
| |
|
The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. |
| | Deep Audio Redundancy (DRED) Extension for the Opus Codec |
| |
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. |
| | Policy Considerations for Changes to RFCs |
| |
|
This document describes policies applicable when the text of an RFC is modified after it has been approved for publication. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-rswg-rfc-changes/. Discussion of this document takes place on the RSWG Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. |
| | Routing Consideration for Satellite Constellation Network |
| |
|
The 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on a satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves somewhat significant work to be explored in the IETF domain. This draft stems from the latest 3GPP satellite use cases, and lands on summarizing the restrictions & challenges in term of satellite-based routing. Based on some unique & advantageous characteristics associated with satellite movement, the draft raises briefly the general design principles and possible algorithms for the integrated NTN+TN routing, while leaves the implementation details for further expansion. |
| | FC-BGP Protocol Specification |
| |
|
This document describes Forwarding Commitment BGP (FC-BGP), an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. Forwarding Commitment（FC）is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in BGP UPDATE and validate network forwarding on the data plane. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP |
| |
|
This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. |
| | DTNMA Application Resource Identifier (ARI) |
| |
| | draft-ietf-dtn-ari-00.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Edward Birrane, Emery Annis, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. |
| | DTNMA Application Management Model (AMM) and Data Models |
| |
| | draft-ietf-dtn-adm-00.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a data model that captures the information necessary to asynchronously manage applications within the Delay- Tolerant Networking Management Architecture (DTNMA). This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements. |
| | YANG Module for BGP Communities |
| |
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardised format. |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
| |
| | draft-gazdag-x509-slhdsa-00.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 205 Stateless Hash-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for HSS and XMSS |
| |
| | draft-gazdag-x509-shbs-00.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies algorithm identifiers and ASN.1 encoding formats for the Stateful Hash-Based Signature Schemes (S-HBS) Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when those digital signatures are used in Internet X.509 certificates and certificate revocation lists. |
| | Mobility Capability Negotiation |
| |
| | draft-yan-dmm-man-13.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Zhiwei Yan, Tianji Jiang, Jianfeng Guan, Tao Huang, Jong-Hyouk Lee |
| | Working Group: |
Individual Submissions (none) |
|
Mobile peers exchange signals with networks, for both wireline and wireless domains, to negotiate capabilities for mobile registration, connection management, session establishment, service provisioning, etc. Generally, mobility capabilities include the supported and provisioned resources along with associated protocols for certain mobility management scenarios. While devices in the mobile wireline (IP) domain would mostly focus on the IP-related negotiation, devices in the wireless domain, e.g., the 5G system (5GS), embrace both mobile IP-related resources as well as wireless-specific capabilities. Regarding both the mobile-IP and wireless domains, we have generalized two protocol categories for mobility capability negotiation & management, i.e., the host-initiated category that involves the direct & active engagement of mobile end devices vs. the network-based category over which mobile endpoints play almost no role in the process. The classification and then the application of the two categories help us analyze the mobility capability negotiation for both the mobile IPv6 and the 3GPP 5G system. The comparison of the capability negotiation under both the Home-Routed (HR) and the Local BreakOut (LBO) roaming cases in 5GS further reflects the feasibility of the protocol dichotomy. |
| | IPv6 Formal Anycast Addresses and Functional Anycast Addresses |
| |
|
Currently, IPv6 anycast addresses are chosen from within the existing IPv6 unicast address space, with the addresses nominated as anycast addresses through configuration. An alternative scheme would be to have a special class of addresses for use as anycast addresses. This memo proposes a distinct general anycast addressing class for IPv6, and a more specific scheme for functional anycast addresses. |
| | IPv4 Extension Headers and Flow Label |
| |
|
This specification defines extension headers for IPv4 and an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. |
| | Trusted Path Routing |
| |
|
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. |
| | SRv6-based BGP Service Capability |
| |
|
This draft describes the problems that may be encountered during the deployment of SRv6-based BGP services in the co-existence scenario where the network supports both SRv6 and MPLS in a given domain, and the possible solutions. |
| | EVPN First Hop Security |
| |
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures for Ethernet VPN (EVPN) will distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi-homing. |
| | Infight Removal of IPv6 Hop-by-Hop and Routing Headers |
| |
|
This document specifies an experimental method to allow routers to remove IPv6 Hop-by-Hop Options or Routing headers from packets in- flight. The goal is to reduce the probability of packets being dropped because they contain extension headers, without adversely impacting functionality. An additional goal is to limit visibility of information in extension headers to those nodes that need to process the headers. |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | Best Practices for Link-Local Connectivity in URI-Based Protocols |
| |
|
Link-local IP connectivity allows hosts on the same network to communicate with each other without the need for centralized IP addressing infrastructure. The IP prefixes 169.254.0.0/16 and fe80::/10 were reserved for this purpose. However, both IP versions have limitations that make link-local addresses unideal for usage with URI-based protocols. This document provides guidance for how best to enable link-local connectivity in such protocols. This document also obsoletes RFC 6874, a previous attempt at solving this issue. |
| | A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET |
| |
|
This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter- domain SAV and is ready to establish neighbor relationship for preventing source address spoofing. |
| | Finding and Using Geofeed Data |
| |
| | draft-ietf-opsawg-9092-update-11.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Randy Bush, Massimo Candela, Warren Kumari, Russ Housley |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed data files. This document obsoletes RFC 9092. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-03.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The presence of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, since the assumptions about the intractability of the mathematical problems for these algorithms that offer confident levels of security today no longer apply in the presence of a CRQC. This means there is a requirement to update protocols and infrastructure to use post-quantum algorithms, which are public-key algorithms designed to be secure against CRQCs as well as classical computers. These new public-key algorithms behave similarly to previous public key algorithms, however the intractable mathematical problems have been carefully chosen so they are hard for CRQCs as well as classical computers. This document explains why engineers need to be aware of and understand post-quantum cryptography. It emphasizes the potential impact of CRQCs on current cryptographic systems and the need to transition to post-quantum algorithms to ensure long-term security. The most important thing to understand is that this transition is not like previous transitions from DES to AES or from SHA-1 to SHA-2. While drop-in replacement may be possible in some cases, others will require protocol re-design to accommodate significant differences in behavior between the new post-quantum algorithms and the classical algorithms that they are replacing. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-11.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-10.txt |
| | Date: |
22/02/2024 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| |
|
| |
| | Attacks on the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-core-attacks-on-coap-04.txt |
| | Date: |
21/02/2024 |
| | Authors: |
John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess |
| | Working Group: |
Constrained RESTful Environments (core) |
|
Being able to securely retrieve information from sensors and control actuators while providing guards against distributed denial-of- service (DDoS) attacks are key requirements for CoAP deployments. To that aim, a security protocol (e.g., DTLS, TLS, or OSCORE) can be enabled to ensure secure CoAP operation, including protection against many attacks. This document identifies a set of known CoAP attacks and shows that simply using CoAP with a security protocol is not always enough for secure operation. Several of the identified attacks can be mitigated with a security protocol providing confidentiality and integrity combined with the solutions specified in RFC 9175. |
| | DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID |
| |
| | draft-ietf-drip-auth-49.txt |
| | Date: |
21/02/2024 |
| | Authors: |
Adam Wiethuechter, Stuart Card, Robert Moskowitz |
| | Working Group: |
Drone Remote ID Protocol (drip) |
|
The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. |
| | Update to the ipn URI scheme |
| |
|
This document updates both the specification of the ipn URI scheme previously defined in RFC 7116 and the rules for encoding of these URIs when used as an Endpoint Identifier (EID) in Bundle Protocol Version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the ipn URI scheme, define encodings of ipn scheme URIs, and establish the registries necessary to manage this scheme. |
| | Test Protocol for One-way IP Capacity Measurement |
| |
|
This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements. |
| | System-defined Configuration |
| |
|
This document defines how a management client and server handle YANG- modeled configuration data that is defined by the server itself. The system-defined configuration can be referenced (e.g. leafref) by configuration explicitly created by a client. The Network Management Datastore Architecture (NMDA) defined in RFC 8342 is updated with a read-only conventional configuration datastore called "system" to hold system-defined configuration. As an alternative to clients explicitly copying referenced system- defined configuration into the target configuration datastore (e.g., ) so that the datastore is valid, a "resolve-system" parameter is defined to allow the server acting as a "system client" to copy referenced system nodes automatically. This solution enables clients manipulating the target configuration datastore (e.g., ) to reference nodes defined in , override system- provided values, and configure descendant nodes of system-defined configuration. This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040. |
| | MISP taxonomy format |
| |
|
This document describes the MISP taxonomy format, a simple JSON format used to represent machine tags (also known as triple tags) vocabularies. A public directory, known as MISP taxonomies, is available and utilizes the MISP taxonomy format. These taxonomies are employed to classify cybersecurity events, threats, suspicious events, or indicators. |
| | Arm's Platform Security Architecture (PSA) Attestation Token |
| |
|
The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with ARM's architecture. It is not a standard nor a product of the IETF. |
| | PCEP Extensions for sid verification for SR-MPLS |
| |
|
This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. |
| | BFD Extension for DetNet Remote Defect Indication (RDI) |
| |
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. |
| | MicroTap Segment in Segment Routing |
| |
| | draft-zzhang-spring-microtap-segment-02.txt |
| | Date: |
21/02/2024 |
| | Authors: |
Zhaohui Zhang, Ryan Hoffman, Gurminderjit Bajwa, Dan Voyer, Shay Zadok, Aijun Wang, Luay Jalil, Li, Siva Sivabalan |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | A Routing Architecture for Satellite Networks |
| |
|
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links that are far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital mechanics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms, enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. |
| | Stand-in Tags for YANG-CBOR |
| |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. |
| | Circuit Style Segment Routing Policies with Optimized SID List Depth |
| |
|
Service providers require delivery of circuit-style transport services in a segment routing based IP network. This document introduces a solution that supports circuit style segment routing policies that allows usage of optimized SID lists (i.e. SID List that may contain non-contiguous node SIDs as instructions) and describes mechanisms that would allow such encoding to still honor all the requirements of the circuit style policies notably traffic engineering and bandwidth requirements. |
| | Cedar Profile for OAuth 2.0 Rich Authorization Requests |
| |
|
This specification defines a profile of OAuth 2.0 Rich Authorization Requests in Cedar policy format within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to distribute and recieve relevant Cedar policy sets in an interoperable manner. |
| | Amplification Attacks Using the Constrained Application Protocol (CoAP) |
| |
|
Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. |
| | TEEP Usecase for Confidential Computing in Network |
| |
|
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC and other scenarios to use confidential computing in network. |
| |
|
| |
| | Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction and evolvement of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry the NRP related information in data packets, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. |
| | YANG Data Model for Topology Filter |
| |
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. |
| | Knowledge Transmission Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel |
| |
|
The document specifies new DOTS data channel configuration parameters that customize the DDoS knowledge transmission configuration between distributed knowledge bases. These options enable assist the distributed knowledge base to share attack knowledge in different fields and actively adapt to dynamically changing DDoS attacks. |
| | A UDP-based GMA (Generic Multi-Access) Protocol |
| |
|
A device can simultaneously connect to multiple access networks, e.g., Wi-Fi, LTE, 5G, DSL, and SATCOM (Satellite Communications). It is desirable to seamlessly combine multiple connections over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built-in multi- path capabilities. This document presents a new convergence protocol for managing data traffic across multiple network paths. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations to experiment with the protocol. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTP |
| |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a Hypertext Transfer Protocol (HTTP) connection. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Replay Resistant Authenticated Receiver Chain |
| |
|
DKIM (RFC6376) is an IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit. Section 8.6 defines a vulnerability called DKIM Replay as a spam message sent through a SMTP MTA DKIM signer, that then is sent to many more recipients, leveraging the reputation of the signer. We propose a replay resistant cryptographic based protocol that discloses all SMTP recipients and signs them, allowing a receiver or any third party to verify that the message went to the intended recipient. If not then then potentially the message is replayed. Moreover it leverages ARC (RFC8617) and sender defined forwarding path to build a "chain of custody" that accurately defines the SMTP forwarding path of the message. This also allows the protocol to detect DKIM and ARC replay attacks and other attacks. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for SD-WAN CPEs using GENEVE Encapsulation (RFC8926) to encapsulate the IPsec encrypted packets and send them to their closest Cloud GWs, who can steer the IPsec encrypted payload through the Cloud Backbone without decryption to the egress Cloud GWs which then forward the original IPsec encrypted payload to the destination CPEs. This method is for Cloud Backbone to connect multiple segments of SD-WAN without the Cloud GWs decrypting and re- encrypting the payloads. |
| | Performance Measurement with Asymmetrical Packets in STAMP |
| |
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | Tolerating Mailing-List Modifications |
| |
|
Mailing-lists distribute email to multiple recipients by forwarding and potentially modifying messages to document the distribution to the recipients. Unfortunately forwarding breaks SPF (RFC7208) authentication and message modification breaks DKIM (RFC6376) authentication. This document is based on ARC (RFC8617) to provide a framework to describe forwarding with extensions to tolerate common mailing-list message modifications. This specification characterizes the mailing-list transforms such that a receiver can reverse them to enable digital signatures verification and attribution of the message content. These message modifications are: 1) adding a description string to the Subject header, 2) rewriting the From header, 3) removing the original DKIM-Signature and 4) appending a footer to the message body. This also specifies those modifications for the purpose of making them reversible. |
| | Implementation and Performance Evaluation of PDM using eBPF |
| |
| | draft-elkins-ebpf-pdm-ebpf-00.txt |
| | Date: |
20/02/2024 |
| | Authors: |
Nalini Elkins, Chinmaya Sharma, Amogh Umesh, Balajinaidu V, Mohit Tahiliani |
| | Working Group: |
Individual Submissions (none) |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. |
| | Implementation and Performance Evaluation of PDM using eBPF |
| |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As kernel implementation can be complex and time-consuming, this document describes the implementation of the Performance and Diagnostic Metrics (PDM) extension header using eBPF in the Linux kernel's Traffic Control (TC) subsystem. The document also provides a performance analysis of the eBPF implementation in comparison to the traditional kernel implementation. |
| | Stream Namespaces for QUIC |
| |
|
QUIC Stream Namespaces provide an extension to the QUIC protocol that enables multiplexing multiple logical groups of streams within the same connection, while providing flow control isolation. |
| | Keep inter-domain forwarding conformance to routing |
| |
|
This document introduces what the conformance forwarding is and why nonconformance forwarding is prevalent in the Internet, describes the risks of nonconformance forwarding and defines the requiremenets for conformance forwarding. |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-09.txt |
| | Date: |
20/02/2024 |
| | Authors: |
Francois Clad, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Scoped DNS Challenges |
| |
|
This document outlines a new challenge for the ACME protocol, enabling an ACME client to answer a domain control validation challenge from an ACME server using a DNS resource linked to the ACME Account ID. This allows multiple systems or environments to handle challenge-solving for a single domain. |
| | Considerations for Benchmarking Network Performance in Containerized Infrastructures |
| |
|
Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resources allocation and network technologies are specified for containerized network functions. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. |
| | CDNI Metadata for Delegated Credentials |
| |
|
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document defines metadata in the CDNI Control and Metadata interface to setup HTTPS delegation using delegated credentials from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). |
| | Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) |
| |
|
This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead. |
| | Grant Negotiation and Authorization Protocol Resource Server Connections |
| |
|
GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This extension defines methods for resource servers (RS) to connect with authorization servers (AS) in an interoperable fashion. |
| | SR Policy Extensions for Path Segment and Bidirectional Path |
| |
|
A Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. For each SR path, it may also have its own path attributes, and Path Segment is one of them. A Path Segment is defined to identify an SR path, which can be used for performance measurement, path correlation, and end-2-end path protection. Path Segment can be also used to correlate two unidirectional SR paths into a bidirectional SR path which is required in some scenarios, for example, mobile backhaul transport network. This document defines extensions to BGP to distribute SR policies carrying Path Segment and bidirectional path information. |
| | SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS |
| |
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. |
| | JMAP REST Mapping |
| |
|
This document specifies a REST Mapping for JMAP endpoints to impose fewer requirements on applications compared to conventional JMAP endpoints. |
| | LISP Predictive RLOCs |
| |
|
This specification describes a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs. |
| | LISP EID Anonymity |
| |
|
This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. |
| | LISP Control-Plane ECDSA Authentication and Authorization |
| |
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. |
| | Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks |
| |
|
The Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A network may consist of multiple IGP domains or multiple Autonomous Systems(ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains. This document describes mechanisms to facilitate LSP ping and traceroute in inter-AS/inter-domain SR- MPLS networks in an efficient manner with a simple Operations, Administration and Maintenance (OAM) protocol extension which uses data plane forwarding alone for forwarding echo replies on transit nodes. |
| | LISP for the Mobile Network |
| |
|
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | Deprecation Of The IPv6 Router Alert Option |
| |
|
This document deprecates the IPv6 Router Alert Option. Protocols that use the Router Alert Option may continue to do so, even in future versions. However, protocols standardized in the future must not use the Router Alert Option. |
| | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| | draft-sajassi-bess-rfc8317bis-01.txt |
| | Date: |
19/02/2024 |
| | Authors: |
Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger |
| | Working Group: |
Individual Submissions (none) |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in [RFC7387], "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of [RFC7796], "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by [RFC7385]; hence, it updates [RFC7385] accordingly. This document obsoletes [RFC8317]. |
| | Signaling Aggregate Header Size Limit via IGP |
| |
|
This document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node to for efficient packet processing. Aggregate header limit is the total header size(e.g, in IPv6, it includes the IPv6 header chain as well as any headers that are part of network encapsulation that precedes the innermost transport layer) that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-wiggers-hbs-state-00.txt |
| | Date: |
19/02/2024 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Individual Submissions (none) |
|
Stateful Hash-Based Signature Schemes (S-HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large- scale quantum computers. Unlike conventional stateless digital signature schemes, S-HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered. |
| | Identifying Email Forwarding |
| |
|
Forwarded email often becomes unauthenticated because it breaks SPF (RFC7208) authentication and DKIM (RFC6376) authentication. For example mailing-lists distribute email to multiple recipients through a separate server than the original sending server that breaks IP based SPF authentication and potentially may modify the message that breaks the DKIM signature. This document calls for using ARC (RFC8617) to identify and authenticate forwarded emails by further specifying the naming of the two digital signatures present in ARC headers- the message signature and the seal. Because this uses ARC digital signature, the receiver has confidence that a valid signature corresponding to some forwarder only could have been generated by the named domain. This document also specifies that all forwarded mail flows have associated ARC headers and the means to characterize the mail flows. |
| | Reverse Tunnel over HTTP |
| |
|
This document specifies an HTTP extension to establish bi-directional byte streams in the direction from servers to their clients, utilizing HTTP as a tunneling mechanism. This approach not only facilitates communication between servers located behind firewalls and their known clients but also introduces the potential for these known clients to serve as relays. In such configurations, clients can forward application protocol messages or relay TCP connections, allowing servers to interact with any client on the Internet without direct exposure. |
| | Network Virtualization Overlays (NVO3) Encapsulation Considerations |
| |
|
The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at starting from the output of an NVO3 encapsulation design team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats. There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. Based on these considerations, the Working Group determined that Geneve with a few modifications as the common encapsulation. This document provides more details, particularly in Section 7. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-01.txt |
| | Date: |
19/02/2024 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification defines a mechanism to preserve identity information and federate authorization across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. |
| |
|
| |
| | Tethering A BIER Router To A BIER incapable Router |
| |
| | draft-ietf-bier-tether-05.txt |
| | Date: |
16/02/2024 |
| | Authors: |
Zhaohui Zhang, Nils Warnke, IJsbrand Wijnands, Daniel Awduche |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document specifies optional procedures to optimize the handling of Bit Index Explicit Replication (BIER) incapable routers, by attaching (tethering) a BIER router to a BIER incapable router. |
| | NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all relevant PTP modes and operates completely independent of NTPv4. |
| | WBA OpenRoaming Wireless Federation |
| |
| | draft-tomas-openroaming-02.txt |
| | Date: |
16/02/2024 |
| | Authors: |
Bruno Tomas, Mark Grayson, Necati Canpolat, Betty Cockrell, Sri Gundavelli |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. |
| | ACME PQC Algorithm Negotiation |
| |
|
ACME is a critical protocol for accelerating HTTPS adoption on the Internet, automating digital certificate issuing for web servers. Because RFC 8555 assumes that both sides (client and server) support the primary cryptographic algorithms necessary for the certificate, ACME does not include algorithm negotiation procedures. However, in light of Post-Quantum Cryptography (PQC), many signature algorithm alternatives can be used, allowing for different trade-offs (e.g., signature vs. public key size). In addition, alternative PQC migration strategies exist, such as KEMTLS, which employs KEM public keys for authentication. This document describes an algorithm negotiation mechanism for ACME. The negotiation allows different strategies and provides KEMTLS certificate issuing capabilities. |
| | Adding a Wrong Recipient URL for Handling Misdirected Emails |
| |
|
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dweekly.github.io/ietf-wrong-recipient/draft-dweekly-wrong- recipient.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/. Source for this draft and an issue tracker can be found at https://github.com/dweekly/ietf-wrong-recipient. |
| | Transport Layer Security (TLS) Authentication with Verifiable Credential (VC) |
| |
|
This document defines a new certificate type and extension for the exchange of Verifiable Credentials in the handshake of the Transport Layer Security (TLS) protocol. The new certificate type is intended to add the Verifiable Credentials as a new means of authentication. The resulting authentication process leverages a distributed ledger as the root of trust of the TLS endpoints' public keys. The endpoints can use different distributed ledger technologies to store their public keys and to perform the TLS handshake. |
| | QUIC on Streams |
| |
|
This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-quic-quic-on-streams. |
| | HTTP/3 on Streams |
| |
|
This document specifies how to use HTTP/3 on top of bi-directional, byte-oriented streams such as TLS over TCP. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. |
| | OAuth Cookie Response Mode |
| |
|
This specification defines a response mode for OAuth 2.0 that uses a cookie to obtain and transmit an access token. In this mode, the access token is encoded using an HTTP Set-Cookie header and transmitted via the HTTP Cookie header to the client or resource server. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-22.txt |
| | Date: |
16/02/2024 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| | Operational Issues with Processing of the Hop-by-Hop Options Header |
| |
| | draft-ietf-v6ops-hbh-10.txt |
| | Date: |
16/02/2024 |
| | Authors: |
Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra |
| | Working Group: |
IPv6 Operations (v6ops) |
|
This document describes the processing of the Hop-by-Hop Options Header (HBH) in current routers in the aspects of standards specification, common implementations, and default operations. This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how HBH Options Header could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The purpose of this draft is to document reasons why HBH Options Header is rarely used within networks. It motivates the benefits and requirements needed to enable wider use of HBH Options. |
| |
|
| |
| | RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec |
| |
|
This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an application layer protocol that provides end-to-end capability exchange, packetization/de-packetization of media, reliable transport, and payload encryption. SCIP handles packetization/de-packetization of the encrypted media and acts as a tunneling protocol, treating SCIP payloads as opaque octets to be encapsulated within RTP payloads prior to transmission or decapsulated on reception. SCIP payloads are sized to fit within the maximum transmission unit (MTU) when transported over RTP thereby avoiding fragmentation. SCIP transmits encrypted traffic and does not require the use of Secure RTP (SRTP) for payload protection. SCIP also provides for reliable transport at the application layer, so it is not necessary to negotiate RTCP retransmission capabilities. To establish reliable communications using SCIP over RTP, it is important that middle boxes avoid parsing or modifying SCIP payloads. Because SCIP payloads are confidentiality and integrity protected and are only decipherable by the originating and receiving SCIP devices, modification of the payload by middle boxes would be detected as an integrity failure in SCIP devices, resulting in retransmission and/or communication failure. Middle boxes do not need to parse the SCIP payloads to correctly transport them. Not only is parsing unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and filtering of SCIP payloads by middle boxes would likely lead to ossification of the evolving SCIP protocol. |
| | Operations,Administration,and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane |
| |
|
This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. |
| | Initializing a DNS Resolver with Priming Queries |
| |
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. See Section 1.1 for the list of changes from RFC 8109. |
| | Operational Considerations for BRSKI Registrar |
| |
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. |
| | Resource Allocation Model for Hybrid Switching Networks |
| |
|
The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. |
| | Media Handling Considerations for Wireless Networks |
| |
|
Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. |
| | SIP Product Identifier |
| |
|
Complex telephony networks using SIP as signalling like the IP Multimedia Subsystem (IMS) of the Third Generation Partnership (3GPP) serving different groups of customers like business and retail customers with different products like mobile, fixed and PBX services have the problem of different handling of the services. This may end up in a complex analysis of the signalling syntax before starting the required procedures for calls based on their service provided to the customer. With the introduction of microservice based technologies the complexity increases. This draft describes a generic identification mechanism for SIP dialogs in using an identifier indicating the service/product which the customer is using to allow an efficient processing of the SIP dialog and session. |
| | Discovery of CIDFI-aware Network Elements |
| |
|
Host-to-network signaling and network-to-host signaling can improve the user experience to adapt to network's constraints and share expected application needs, and thus to provide differentiated service to a flow and to packets within a flow. The differentiated service may be provided at the network (e.g., packet prioritization), the server (e.g., adaptive transmission), or both. Such an approach is called CIDFI, for Collaborative and Interoperable Dissemination of Flow Indicators. A key component in a CIDFI system is to discover whether a network is CIDFI-capable, and if so discover a set of CIDFI-aware Network Elements (CNEs) that will be involved in the Host-to-network signaling and network-to-host signaling. This document discusses a set of discovery methods. |
| | The Use of Non-ASCII Characters in RFCs |
| |
|
The RFC Series has evolved to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of RFCs is now in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes requirements and guidelines for the RFC Editor regarding the use of non-ASCII characters in RFCs. This document obsoletes RFC 7997. The differences reflect changes in the practices of the RFC series since RFC 7997 was published, and makes further changes based on agreements in the IETF community about what characters are allowed in RFCs. [[ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ]] |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates IPv6 Neighbor Discovery [RFC4861] and the 6LoWPAN extensions [RFC8505][RFC8928] to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The prefix registration also provides a protocol-independent interface for the node to request neighbor router(s) to redistribute the prefix to the larger routing domain using their specific routing protocols. This document extends RPL [RFC6550][RFC6553][RFC9010] to enable the 6LR to inject the registered prefix in RPL. |
| | BGP MPLS-Based Ethernet VPN |
| |
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". |
| | BIER BFD |
| |
| | draft-ietf-bier-bfd-05.txt |
| | Date: |
13/02/2024 |
| | Authors: |
Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. |
| | Internationalized Email Addresses in X.509 Certificates |
| |
| | draft-ietf-lamps-rfc8398bis-05.txt |
| | Date: |
13/02/2024 |
| | Authors: |
Alexey Melnikov, Wei Chuang, Corey Bonnell |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280 and obsoletes RFC 8398. |
| | Multi-part TLVs in IS-IS |
| |
| | draft-ietf-lsr-multi-tlv-01.txt |
| | Date: |
13/02/2024 |
| | Authors: |
Parag Kaneriya, Tony Li, Tony Przygienda, Shraddha Hegde, Chris Bowers, Les Ginsberg |
| | Working Group: |
Link State Routing (lsr) |
|
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. |
| | The Transit Measurement Option |
| |
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. |
| | Path Computation Based on Precision Availability Metrics |
| |
| | draft-contreras-pce-pam-02.txt |
| | Date: |
13/02/2024 |
| | Authors: |
Luis Contreras, Fernando Agraz, Salvatore Spadaro |
| | Working Group: |
Individual Submissions (none) |
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. |
| | Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. |
| | Structured Email: Use cases |
| |
|
This document collects and discusses use cases for "structured email" ([I-D.happel-structured-email-00]). |
| |
|
| |
| | BGP-LS Extensions for IS-IS Flood Reflection |
| |
|
IS-IS Flood Reflection is a mechanism that allows flat, single-area IS-IS topologies to scale beyond their traditional limitations. This document defines new BGP-LS (BGP Link-State) TLVs in order to carry IS-IS Flood Reflection information. |
| | IS-IS Optimal Distributed Flooding for Dense Topologies |
| |
|
In dense topologies (such as data center fabrics based on the Clos and butterfly topologies, though not limited to those exclusively), IGP flooding mechanisms designed originally for sparse topologies can "overflood," or in other words generate too many identical copies of topology and reachability information arriving at a given node from other devices. This normally results in slower convergence times and higher resource utilization to process and discard the superfluous copies. The modifications to the flooding mechanism in the Intermediate System to Intermediate System (IS-IS) link state protocol described in this document reduce resource utilization significantly, while increaseing convergence performance in dense topologies. Beside reducing the extraneous copies it uses the dense topologies to "load-balance" flooding across different possible paths in the network to prevent build up of flooding hot-spots. Note that a Clos fabric is used as the primary example of a dense flooding topology throughout this document. However, the flooding optimizations described in this document apply to any arbitrary topology. |
| | Performance Measurement for Segment Routing Networks with MPLS Data Plane |
| |
| | draft-ietf-mpls-rfc6374-sr-09.txt |
| | Date: |
09/02/2024 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Stefano Salsano, Mach Chen |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to Multiprotocol Label Switching data plane (SR-MPLS) as specified in RFC 8402. RFC 6374 and RFC 7876 specify protocol mechanisms to enable efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks. RFC 9341 defines Alternate-Marking Method using Block Number (BN) for data correlation mechanism for packet loss measurement. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR-MPLS networks, for both links and end-to-end SR-MPLS paths including Policies. |
| | Impact of DLTs on Provider Networks |
| |
|
This document discusses the impact of distributed ledger technologies being realized over IP-based provider networks. The focus here lies on the impact that the DLT communication patterns have on efficiency of resource usage in the underlying networks. We provide initial insights into experimental results to quantify this impact in terms of inefficient and wasted communication, aligned along challenges that the DLT realization over IP networks faces. This document intends to outline this impact but also opportunities for network innovations to improve on the identified impact as well as the overall service quality. While this document does not promote specific solutions that capture those opportunities, it invites the wider community working on DLT and network solutions alike to contribute to the insights in this document to aid future research and development into possible solution concepts and technologies. The findings presented here have first been reported within the similarly titled whitepaper released by the Industry IoT Consortium (IIC) [IIC_whitepaper]. |
| | Auto Edge Protection |
| |
|
This document specifies procedures to automatically establish context based forwarding for providing fast reroute during egress node and egress link failures. It describes how to detect multi-homed services and establish context for forwarding. It also defines procedures to avoid conflicts among routers while establishing context. |
| | Hybrid IANA Registration Policy |
| |
|
The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies. |
| | MASQUE extension for signaling media bitrate |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal the available bitrate for media traffic that is proxied through an HTTP server. This information can be used by a media application to regulate its media bitrate in accordance with a network policy, as an alternative to in-network traffic shaping. |
| | Chunked Oblivious HTTP Messages |
| |
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. |
| | Segment Protection for SR-TE Paths |
| |
|
Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension |
| |
| | draft-ietf-acme-ari-03.txt |
| | Date: |
08/02/2024 |
| | Authors: |
Aaron Gable |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies how an ACME server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods. |
| | Kerberos SPAKE Pre-Authentication |
| |
|
This document defines a new pre-authentication mechanism for the Kerberos protocol. The mechanism uses a password-authenticated key exchange to prevent brute-force password attacks, and may optionally incorporate a second factor. |
| | Vehicular Neighbor Discovery for IP-Based Vehicular Networks |
| |
|
This document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular networks. An optimized Address Registration and a multihop Duplicate Address Detection (DAD) mechanism are performed for having operation efficiency and also saving both wireless bandwidth and vehicle energy. In addition, three new ND options for prefix discovery, service discovery, and mobility information report are defined to announce the network prefixes and services inside a vehicle (i.e., a vehicle's internal network). |
| | DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based Vehicular Networks |
| |
|
This document specifies an autoconfiguration scheme for device discovery and service discovery in IP-based vehicular networks. Through the device discovery, this document supports the global (or local) DNS naming of Internet-of-Things (IoT) devices, such as sensors, actuators, and in-vehicle units. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's model information in wired and wireless target networks (e.g., vehicle, road network, home, office, shopping mall, and smart grid). Through the service discovery, IoT users (e.g., drivers, passengers, home residents, and customers) in the Internet (or local network) can easily identify each device for monitoring and remote-controlling it in a target network. |
| | Vehicular Mobility Management for IP-Based Vehicular Networks |
| |
|
This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory. |
| | Basic Support for Security and Privacy in IP-Based Vehicular Networks |
| |
|
This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks. |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-08.txt |
| | Date: |
08/02/2024 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. This protocol extension has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale deployment to determine the potential benefits of this approach. |
| | Interworking of GMPLS Control and Centralized Controller Systems |
| |
|
Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issues from multi- domain, multi-vendor, and multi-technology. An example of such centralized architecture is Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy described in RFC 8453. Instead of competing with each other, both the distributed and the centralized control plane have their own advantages, and should be complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network. |
| |
|
| |
| | LSR Extensions for BIER non-MPLS Encapsulation |
| |
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document updates RFC8296 and specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non- MPLS networks using BIER non-MPLS encapsulation. |
| | AS Path Prepending |
| |
| | draft-ietf-grow-as-path-prepending-12.txt |
| | Date: |
07/02/2024 |
| | Authors: |
Mike McBride, Doug Madory, Jeff Tantsura, Robert Raszuk, Hongwei Li, Jakob Heitz, Gyan Mishra |
| | Working Group: |
Global Routing Operations (grow) |
|
AS Path Prepending provides a tool to manipulate the BGP AS_PATH attribute through prepending multiple entries of an ASN. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the Internet. This document provides guidance for the use of AS Path Prepending, including alternative solutions, in order to avoid negatively affecting the Internet. |
| | Guidelines for Security Policy Translation in Interface to Network Security Functions |
| |
|
This document proposes the guidelines for security policy translation in Interface to Network Security Functions (I2NSF) Framework. When I2NSF User delivers a high-level security policy for a security service, Security Policy Translator in Security Controller translates it into a low-level security policy for Network Security Functions (NSFs). For this security policy translation, this document specifies the relation between a high-level security policy based on the Consumer-Facing Interface YANG data model and a low-level security policy based on the NSF-Facing Interface YANG data model. Also, it describes an architecture of a security policy translator along with an NSF database, and the process of security policy translation with the NSF database. |
| | Security Management Automation of Cloud-Based Security Services in I2NSF Framework |
| |
|
This document describes Security Management Automation (SMA) of cloud-based security services in the framework of Interface to Network Security Functions (I2NSF). The security management automation in this document deals with closed-loop security control, security policy translation, and security audit. To support these three features in SMA, this document specifies an augmented architecture of the I2NSF framework with new system components and new interfaces. |
| | EVPN multi-homing support for L3 services |
| |
|
This document introduces the utilization of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to enhance network availability and load balancing for various L3 services in EVPN. |
| | I2NSF Analytics Interface YANG Data Model |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF system in a Network Functions Virtualization (NFV) environment. The YANG data model described in this document is based on the I2NSF NSF- Facing Interface and the I2NSF Monitoring Interface for enabling the delivery of analytics information based on monitoring data received from a Network Security Function (NSF). |
| | The DNSCrypt protocol |
| |
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/. Source for this draft and an issue tracker can be found at https://github.com/DNSCrypt/dnscrypt-protocol. |
| | EVPN Anycast Aliasing For Multi-Homing |
| |
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function addresses the load balancing of unicast packets from remote Network Virtualization Edge (NVE) devices to the NVEs that are multi-homed to the same CE, irrespective of the learning of the CE's MAC/IP information on the NVEs. This document describes an optional optimization of the EVPN multi-homing Aliasing function - EVPN Anycast Aliasing - that is specific to the use of EVPN with NVO3 tunnels (i.e., IP tunnels) and, in typical Data Center designs, may provide savings in terms of data plane and control plane resources in the routers. |
| | IPv6 Address Assignment for SRv6 |
| |
|
This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios. |
| | A Network Inventory Location Model |
| |
|
This document defines a Yang data model for Network Inventory location, e.g. site, room, rack, geo-location data, which is used to provide location information with different granularities for network inventory items (such as Network Elements, device components). Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from Network Elements and therefore is not included in the base Network Inventory model defined in draft-ietf- ivy-network-inventory-yang. The purpose of this document is to define a location model for network inventory that extends the base inventory with comprehensive location data. |
| | WebRTC-HTTP ingestion protocol (WHIP) |
| |
| | draft-ietf-wish-whip-13.txt |
| | Date: |
07/02/2024 |
| | Authors: |
Sergio Murillo, Alex Gouaillard |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This document updates RFC 8842 and RFC 8840. |
| |
|
| |
| | BIER Penultimate Hop Popping |
| |
|
Bit Index Explicit Replication (BIER) can be used as provider tunnel for Multicast Virtual Private Network (MVPN), Global Table Multicast or Ethernet Virtual Private Network (EVPN). It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER-incapable transit routers. However those methods assume the MVPN/EVPN Provider Edges (PEs) are BIER- capable. This document specifies a method to allow BIER-incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BIER Forwarding Router (BFR) that is connected directly or indirectly via a tunnel to a BIER-incapable PE remove the BIER header and send the payload to the PE. |
| | Multicast/BIER As A Service |
| |
|
This document describes a framework for providing multicast as a service via Bit Index Explicit Replication (BIER) [RFC7279], and specifies a few enhancements to [draft-ietf-bier-idr-extensions] [RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service. |
| | KangarooTwelve and TurboSHAKE |
| |
|
This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. |
| | BMP Peer Up Message Namespace |
| |
|
RFC 7854, BMP, uses different message types for different purposes. Most of these are Type, Length, Value (TLV) structured. One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Subsequent experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol. This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFC 8671 and RFC 9069 by moving the defined codepoints in the newly introduced registry. The changes in this document are formal only, compliant implementations of RFC 7854, RFC 8671 and RFC 9069 also comply with this specification. |
| | Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) |
| |
| | draft-ietf-lamps-cms-kemri-08.txt |
| | Date: |
06/02/2024 |
| | Authors: |
Russ Housley, John Gray, Tomofumi Okubo |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. |
| | BGP Blockchain |
| |
|
A variety of mechanisms have been developed and deployed over the years to secure BGP including the more recent RPKI/ROA mechanisms. Is it also possible to use a distributed ledger such as Blockchain to secure BGP? BGP provides decentralized connectivity across the Internet. Blockchain provides decentralized secure transactions in a append-only, tamper-resistant ledger. This document reviews possible opportunities of using Blockchain to secure BGP policies within a domain and across the global Internet. We propose that BGP data could be placed in a blockchain and smart contracts can control how the data is managed. This could create a single source of truth, something for which blockchains are particularly well suited. |
| | In-band Task Provisioning for DAP |
| |
|
An extension for the Distributed Aggregation Protocol (DAP) is specified that allows the task configuration to be provisioned in- band. |
| | mLDP/RSVP-TE P2MP Tunnel with SRv6 SID |
| |
|
This document specifies extensions to mLDP and RSVP-TE P2MP protocols to set up mLDP and RSVP-TE P2MP tunnels with SRv6 SIDs intead of MPLS labels. |
| | BIER with Anycast |
| |
| | draft-zzhang-bier-anycast-03.txt |
| | Date: |
06/02/2024 |
| | Authors: |
Zhaohui Zhang, IJsbrand Wijnands, Zheng Zhang, Mankamana Mishra, Huaimo Chen |
| | Working Group: |
Individual Submissions (none) |
|
BIER architecture currently does not support anycast, in that each BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR- ID. BIER signaling protocols also check if there are duplicate BFR- IDs advertised. This document discusses and specifies anycast support with BIER. It updates RFC 8279, RFC 8401 and RFC 8444. |
| | BIER Flow Overlay with Anycast Egress Protection |
| |
|
This document discusses considerations and specifies procedures for multicast flow overlay when BIER Anycast is used for egress protection in the context of MVPN and EVPN. Future revisions will cover other flow overlay protocols like PIM/MLD/mLDP. |
| | ANUP Implementation in 5G with BGP Signaling |
| |
|
Draft-zzhang-dmm-mup-evolution describes an architecture in which co- located Access Node and User Plane Function node of a 5G mobile network are integrated into a single Network Function ANUP in 6G for simplified signaling and optimized forwarding. The integration can happen in 5G as well but only with optimized forwarding. This document describes how BGP signaling specified in Draft-mpmz-bess- mup-safi can be used for ANUP implementation in 5G. |
| | VPN Inter-AS Option BC |
| |
|
RFC 4364 specifies protocol and procedures for BGP/MPLS IP Virtual Private Networks (VPNs), including different options (A/B/C) of Inter-AS support. This document specifies MPLS VPN Inter-AS Option BC that combines the advantages of Option B and Option C (and that removes the disadvantages of Option B and Option C). The same concept is applicable to Ethernet Virtual Private Network (EVPN) as well. |
| | End Marker in 5G Data Network |
| |
|
In a mobile network, when a mobile device (referred to as User Equipment or UE) moves from one Access Node (source AN) to another (target AN), the anchoring node that connects the UE to the Data Network sends an End Marker to the source AN after it starts sending UE traffic towards the target AN. The target AN buffers the data until it receives the End Marker forwarded by the source AN. This is to preserve the order of packets during the handover between ANs. The anchoring node is referred to as User Plane Function (UPF) in 5G and it is a Network Function of the mobile network. The UPFs are traditionally centrally deployed but are more and more distributed closer to the edge. With distributed UPFs, handover becomes necessary among UPFs, and the End Marker mechanism may need to be extended to Data Network devices that are not mobile network functions. This document discusses the problem and proposes a solution based on ICMP messages if packet ordering needs to be preserved during handover between UPFs. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers |
| |
|
Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields defined in RFC 9197 can be used for recording and collecting Hop-By-Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect any IPv6 options and MPLS Network Action Sub-Stacks for hop-by-hop and edge-to-edge active measurements, including IOAM data fields. |
| | OAuth 2.0 Nonce Endpoint |
| |
|
This document defines the Nonce Endpoint for OAuth 2.0 implementations [RFC6749]. It details how an Authorization Server generates and issues opaque Nonces and how a client can learn about this endpoint to obtain a Nonce generated by the Authorization Server. |
| | RTCP feedback Message Timing Configuration |
| |
|
This specification describes configuring the Real-time Transport Control Protocol (RTCP) message feedback send time. |
| |
|
| |
| | OSPF Extensions for BIER-TE |
| |
| | draft-ietf-bier-te-ospf-10.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Huaimo Chen, Mike McBride, Zheng Zhang, Aijun Wang, Gyan Mishra, Yanhe Fan |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes OSPFv2 and OSPFv3 extensions for distributing the BitPositions configured on a Bit-Forwarding Router (BFR) with MPLS and non-MPLS encapsulation for "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) in a BIER-TE domain. |
| | BIER Fast ReRoute |
| |
| | draft-ietf-bier-frr-04.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a scalable multicast overlay that utilizes a routing underlay, e.g., IP, to build up its Bit Index Forwarding Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-FRR). It protects BIER traffic after detecting the failure of a link or node in the core of a BIER domain until affected BIFT entries are recomputed after reconvergence of the routing underlay. BIER-FRR is applied locally at the point of local repair (PLR) and does not introduce any per-flow state. The document specifies nomenclature for BIER-FRR and gives examples for its integration in BIER forwarding. Furthermore, it presents operation modes for BIER-FRR. Link and node protection may be chosen as protection level. Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based BIER-FRR are defined and compared. |
| | CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals,ABNF,and Media Type |
| |
|
The Concise Binary Object Representation, CBOR (STD 94, RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. This document specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions for text representations of epoch-based date/times and of IP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. To facilitate tool interoperation, this document specifies a formal ABNF definition for extended diagnostic notation (EDN) that accommodates application- oriented literals. |
| | IMAP MESSAGELIMIT Extension |
| |
| | draft-ietf-extra-imap-messagelimit-08.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Luis Alves |
| | Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE/APPEND/EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by corresponding IMAP server and avoid issuing commands that would exceed such limit. |
| | Updates to X.509 Policy Validation |
| |
|
This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure which scaled exponentially in the worst case, leaving implementations vulnerable to denial-of- service attacks. |
| | Flooding Topology Minimum Degree Algorithm |
| |
|
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. |
| | An HTTPS-based Transport for YANG Notifications |
| |
|
This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. |
| | SRv6 Midpoint Protection |
| |
|
The current local repair mechanism, e.g., TI-LFA, allows the upstream neighbor of the failed node or link to fast re-route traffic around the failure. This mechanism does not work properly for SRv6 TE path after the failure happens in an endpoint node and IGP converges on the failure. This document defines midpoint protection for SRv6 TE path, which enables the upstream endpoint node of the failed node to perform the endpoint behavior for the faulty node and fast re-route traffic around the failure after IGP converges on the failure. |
| | BIER Encapsulation for IOAM Data |
| |
| | draft-xzlnp-bier-ioam-07.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro |
| | Working Group: |
Individual Submissions (none) |
|
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header contains a bit- string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data is encapsulated in BIER header. |
| | Guide for building an EC PKI |
| |
| | draft-moskowitz-ec-pki-02.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Robert Moskowitz, Henk Birkholz, Michael Richardson |
| | Working Group: |
Individual Submissions (none) |
|
This memo provides a guide for building a PKI (Public Key Infrastructure) of EC certificates using openSSL. Certificates in this guide can use either ECDSA or EdDSA. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates. |
| | IGP Extensions for Intra-Domain SAV |
| |
| | draft-chen-savnet-lsr-intra-02.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Huaimo Chen, Weiqiang Cheng, Aijun Wang, Gyan Mishra, Yanhe Fan, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies extensions to OSPF and IS-IS for Source Address Validation in Intra-domain. |
| | SR Path Binding Protection Architecture |
| |
|
This document describes a architecture of fast re-route protection for binding SIDs on SR paths including SRv6 paths and SR-MPLS paths. The SR paths are in a single domain or cross two domains. The two domains are administrated by one provider or two different providers. |
| | Paths Limit for Multiple Paths in BGP |
| |
|
This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. |
| | JSON Schema extension to NTV data |
| |
|
The NTV format is an extension of the JSON format integrating a semantic dimension through the notion of type. This format remains compatible with the current JSON format but it is relevant to examine its compatibility and its impacts with data schemas. This document provides some answers to this question and presents some of the possible developments based mainly on the example of JSON Schema and additionally on the example of OpenAPI. |
| | DHCPv4 over DHCPv6 with Relay Agent Support |
| |
|
This document describes a general mechanism for networks with legacy IPv4 only clients to use DHCPv4-over-DHCPv6 (DHCP 4o6) for discovering information about network Topology. To address this scenario, this document specifies an amendment to RFC7341 that allows a new 4o6 Relay Agent (4o6RA) to perform the 4o6 DHCP en- and decapsultion instead of the client. |
| | Deterministic Hashed Data Elision: Problem Statement and Areas of Work |
| |
|
This document discusses the privacy and human rights benefits of data minimization via the methodology of hashed data elision and how it can help protocols to fulfill the guidelines of RFC 6973: Privacy Considerations for Internet Protocols and RFC 8280: Research into Human Rights Protocol Considerations. Additional details discuss how the extant Gordian Envelope draft can provide further benefits in these categories. |
| | PROBE: A Utility for Probing Interfaces |
| |
|
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. |
| | OAuth 2.0 Protected Resource Metadata |
| |
|
This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks |
| |
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End-to-End (E2E) traffic assurance in the Native IP network under PCE as a central controller (PCECC). |
| | Carrying SR-Algorithm information in PCE-based Networks. |
| |
| | draft-ietf-pce-sid-algo-08.txt |
| | Date: |
01/02/2024 |
| | Authors: |
Samuel Sidor, Alex Tokar, Shaofu Peng, Shuping Peng, Andrew Stone |
| | Working Group: |
Path Computation Element (pce) |
|
The SR-Algorithm associated with a Prefix Segment-ID (SID) defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the SR- Algorithm associated with each Prefix SID used in PCE-computed paths, as well as signalling a specific SR-Algorithm as a constraint to the PCE. |
| | SRv6 Path Egress Protection |
| |
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. |