| |
|
| |
| | BGP Colored Prefix Routing (CPR) for SRv6 based Services |
| |
| | draft-ietf-idr-cpr-04.txt |
| | Date: |
30/06/2024 |
| | Authors: |
Haibo Wang, Jie Dong, Ketan Talaulikar, hantao, Ran Chen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored prefixes. This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. The existing IPv6 Address Family and Color Extended Community are reused for the advertisement of IPv6 Colored prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks. |
| | Lzip Compressed Format and the 'application/lzip' Media Type |
| |
|
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. |
| | SR-MPLS / SRv6 Transport Interworking |
| |
| | draft-bonica-spring-srv6-end-dtm-12.txt |
| | Date: |
30/06/2024 |
| | Authors: |
Shraddha Hegde, Parag Kaneriya, Ron Bonica, Shaofu Peng, Greg Mirsky, Zheng Zhang, Bruno Decraene, Dan Voyer, Swadesh Agrawal |
| | Working Group: |
Individual Submissions (none) |
|
This document describes procedures for interworking between an SR- MPLS transit domain and an SRv6 transit domain. Each domain contains Provider Edge (PE) and Provider (P) routers. Area Border Routers (ABR) provide connectivity between domains. The procedures described in this document require the ABR to carry a route to each PE router. However, they do not required the ABR to carry service (i.e., customer) routes. In that respect, these procedures resemble L3VPN Interprovider Option C. Procedures described in this document support interworking for global IPv4 and IPv6 service prefixes. They do not support interworking for VPN services prefixes where the SR-MPLS domain uses MPLS service labels. |
| | 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks |
| |
|
This document defines a new type of segment for Segment Routing, 4map6 segment, which is an IPv4/IPv6 conversion function based on stateless mapping rules running in PE nodes for the delivery of IPv4 services over IPv6-only network. At the same time, the BGP Prefix- SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. |
| | WebTransport over WebSocket |
| |
|
WebTransport [OVERVIEW], a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket [WEBSOCKET], offering WebTransport capabilities similar to the HTTP/2 variant [WEBTRANSPORT-H2]. It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket [WEBSOCKET]. |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines two YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers. Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-tls-client- server * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server |
| | A YANG Data Model for ARP |
| |
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. |
| |
|
| |
| | MISP core format |
| |
|
This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. |
| | Loop avoidance using Segment Routing |
| |
|
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. |
| | 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. |
| | Support of Hostname and Sequencing in YANG Notifications |
| |
|
This document specifies a new YANG module that augments the NETCONF Event Notification header to support the hostname and sequence number to identify from which network node and at which time the message was published. This allows the collector to recognize loss, delay and reordering between the publisher and the downstream system storing the messages. |
| | 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. |
| | Selective Synchronization for RPKI to Router Protocol |
| |
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronizations. The router can obtain only the data that it really needs, and it does not need to save the data that are not needed. |
| | BGP SR Policy Extensions for Path Scheduling |
| |
|
Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths. This document proposes extensions to BGP SR Policy to indicate the enable time and disable time for routing paths to enable path scheduling. |
| | BGP Flow Specification Extensions for Path Scheduling |
| |
|
Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths. This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time. |
| | An Analysis of ASPA-based AS_PATH Verification |
| |
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies. The document can help people deploy ASPA properly and provide some potential directions of enhancing ASPA. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extension for Co-routed Bidirectional Path |
| |
|
This document extends STAM Return Path TLV with a Co-routed Bidirectional Path flag to implement the round-trip performance measurement for specific path. |
| | IGP Extensions for Optimized SRv6 SID Advertisement |
| |
|
When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance. |
| | Expanding the IPv6 Documentation Space |
| |
|
The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
When RFC 6724 was published it defined an address selection algorithm along with a default policy table, and noted a number of examples where that policy table might benefit from adjustment for specific scenarios. It also noted that it is important for implementations to provide a way to change the default policies as more experience is gained. This update draws on several years of such operational experience to refine RFC 6724, with emphasis on preference for the use of ULA addresses over IPv4 addresses and the addition of mandatory support for Rule 5.5. It also defines the concept of "known-local" ULA prefixes and the means by which nodes can identify them and insert them into their policy table such that local ULA-to- ULA communications become preferred over GUA-to-GUA for local use. The update also demotes the preference for 6to4 addresses. These changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-07.txt |
| | Date: |
28/06/2024 |
| | Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| | 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 describes techniques to avoid IP fragmentation in DNS. |
| | DRIP Entity Tag (DET) Identity Management Architecture |
| |
|
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and related metadata is performed via DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is provided in this document with future supporting documents to provide technical specifications. |
| | BGP SR Policy Extensions for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. |
| | YANG Metadata Annotation for Immutable Flag |
| |
|
This document defines a way to formally document existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting existing behavior, not proscriptive, dictating server behavior. |
| | A YANG Data Model for Network Incident Management |
| |
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents by data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and root cause analysis. |
| | Challenges and Opportunities in Management for Green Networking |
| |
| | draft-irtf-nmrg-green-ps-03.txt |
| | Date: |
28/06/2024 |
| | Authors: |
Alexander Clemm, Cedric Westphal, Jeff Tantsura, Laurent Ciavaglia, Carlos Pignataro, Marie-Paule Odini |
| | Working Group: |
Network Management (nmrg) |
|
Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they contribute to this footprint themselves in no insignificant way. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become "greener", i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. |
| | A Decent LISP Mapping System (LISP-Decent) |
| |
|
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. |
| | Architecture and application scenario for fused service function chain |
| |
|
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. |
| | Unicast Use of the Formerly Reserved 240/4 |
| |
|
This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Unicast Use of the Lowest Address in an IPv4 Subnet |
| |
|
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. |
| | Unicast Use of the Formerly Reserved 0/8 |
| |
|
This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Protocol extension and mechanism for fused service function chain |
| |
|
This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. |
| | Supporting In-Situ Operations,Administration,and Maintenance Direct Export Using MPLS Network Actions |
| |
|
In-Situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information that can be used to calculate various performance metrics. IOAM Direct Export (IOAM-DEX) is one of the IOAM Option types, in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the on-path operational state, and telemetry information can be collected using IOAM-DEX Option in combination with MNA. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-08.txt |
| | Date: |
28/06/2024 |
| | Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | IGP Flexible Algorithm with Link Loss |
| |
|
IGP Flexible Algorithms allow IGPs to compute constraint-based paths. Since link packet loss rate plays an important role in network evaluation, links with high packet loss rate should be bypassed during forwarding. This draft proposes a path computation method based on a maximum link loss constraint to prune unsatisfied links in Flexible Algorithms. |
| | TLS Trust Expressions |
| |
|
This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. |
| | 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. |
| | Problem Statement for a Digital Emblem |
| |
|
In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark _physical_ assets. This enables military units to identify assets as respected and protected under international humanitarian law. This draft explores how one could apply the protective emblems to _digital_, network- connected infrastructure using a _digital emblem_, and defines the requirements of a digital emblem, emphasizing security requirements. Notably, a digital emblem has a unique combination of security requirements, namely, authentication, accountability, and a property that we call _covert inspection_. Covert inspection means that those wishing to authenticate assets as protected must be able to do so without revealing that they may attack unprotected entities. |
| | Wrapped ESP Version 2 |
| |
|
This document describes the Wrapped Encapsulating Security Payload v2 (WESPv2) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303]. It is designed to overcome limitations of the ESP protocol to expose inner flow information to the network in a transparent way. To do so, it adapts IPv6 Extension header options to WESPv2 where flow identitiers can be stored. It also defines a Crypt Offset to allow intermediate devices to read some header bytes at the beginning of the inner packet. In particular, this preserves the original use-case of WESP [RFC5840]. |
| | The auth URI scheme |
| |
|
This document describes an URI scheme capable of susbtituting userinfo in traditional URIs, in machine-to-machine contexts, allowing for the deprecation and, in some applications, complete elimination of userinfo from URIs. In particular, the nature of the proposed URI scheme makes it unsuitable for use in semantic attacks, without compromising legitimate use-cases. |
| | YANG Data Model for IPv6 Address Resolution |
| |
|
This document defines a YANG data model to configure and manage IPv6 address resolution based on IPv6 Neighbor Discovery (ND) protocol and other related functions, including proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), and Duplicate Address Detection (DAD). |
| | TLS Trust Anchor Identifiers |
| |
|
This document defines the TLS Trust Anchors extension, a mechanism for relying parties and subscribers to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency. |
| |
|
| |
| | External References to Values in CBOR Diagnostic Notation (EDN) |
| |
| | draft-ietf-cbor-edn-e-ref-00.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
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. |
| | Bundle Protocol Version 7 Administrative Record Types Registry |
| |
|
This document updates RFC 9171 to clarify that a Bundle Protocol Version 7 agent is intended to use an IANA sub-registry for Administrative Record types. It also makes a code point reservation for private or experimental use. |
| | Publicly Verifiable Nominations Committee (NomCom) Random Selection |
| |
|
This document describes a method for making random selections in such a way as to promote public confidence in the unbiased nature of the choice. This method is referred to in this document as "verifiable selection". It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar techniques could be and have been applied to other selections. It provdes an optional extension for multiple rounds of such selection that can be induced by earlier selectees without compromising the unpredictable nature of the selections. This document obsoletes RFC 3797. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-liu-sidrops-rtr-yang-05.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Jeffrey Haas, Hongwei Liu, Di Ma |
| | Working Group: |
Individual Submissions (none) |
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| | Distribution of Service Metadata in BGP-LS |
| |
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS. |
| | Distribution of Service Metadata in BGP FlowSpec |
| |
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST IP address. Its routes along with service metadata can be collected by a central controller. The controller may process the metadata and distribute the result to ingress routers using BGP FlowSpec. The service metadata can be used by ingress routers to make path selections not only based on the routing cost but also on the running environment of the edge services. This document describes a mechanism to distribute the information of the service routes and related service metadata using BGP FlowSpec. |
| | Sloppy Topology Updates for ad-hoc Routing Protocols (STURP) |
| |
| | draft-lou-manet-sturp-02.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Zhe Lou, Luigi Iannone, Dirk Trossen, Zhaochen Shi |
| | Working Group: |
Individual Submissions (none) |
|
This memo describes an approach to updating topologies in typical MANET-like environments, relying on what is termed 'sloppy updates' in the remainder of this document. Key to the approach is that updates are only initiated if existing communication relations may be effect by non-synchronized topology information, otherwise using the topology information as it exists. This 'sloppy' nature of the approach reduces the needed updates and the associated communication for them, thus increases efficiency as well as performance from a user perspective. |
| | Differentiated DetNet QoS for Deterministic Services |
| |
|
This document describes the service requirements of scaling deterministic networks and proposes Differentiated DetNet QoS (DD- QoS) for deterministic services in enhanced DetNet. |
| | BIER Loop Avoidance using Segment Routing |
| |
| | draft-liu-bier-uloop-04.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Yuanxiang Qiu |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a mechanism leveraging SR-MPLS/SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. |
| | Intra-domain SAVNET 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. |
| | Intra-domain SAV Support via BGP |
| |
|
This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes. |
| | A File Format to Aid in Consumer Privacy Enforcement,Research,and Tools |
| |
| | draft-colwell-privacy-txt-01.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Nick Sullivan, Louise Van der Peet, Georgios Smaragdakis, Brien Colwell |
| | Working Group: |
Individual Submissions (none) |
|
This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txt [RFC9309], security.txt [RFC9116], or ads.txt [ADS-TXT], in the / directory or /.well-known directory. The file format adds structured data for three areas: 1. A machine parsable and complete privacy policy 2. Consumer actions under their privacy rights 3. Cookie disclosures |
| | SCONEPRO Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONEPRO metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONEPRO RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONEPRO metadata. |
| | IGP Extensions for Time-based Resource |
| |
|
This document proposes the time-based resources and the distribution by IGP extensions for traffic engineering in control plane to simplify resource management and scheduling in certain networks requiring the latency guarantees. |
| | IGP Extensions for Deterministic Link |
| |
|
This document proposes the deterministic link to provide an one- dimensional metric to indicate the deterministic forwarding capabilities at different levels and proposes the deterministic links distribution by IGP extensions. |
| | Associating Segment Routing (SR) Policy with Network Resource Partition (NRP) |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP) is a subset of the network resources and associated policies in the underlay network, which can be used to support one or a group of Enhanced VPN or RFC 9543 network slice services. In SR networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. Within an NRP, SR Policy can be used for forwarding traffic which is mapped to the NRP, so that the traffic can be provided with the subset of network resources and policy of the NRP for guaranteed performance. The association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. |
| | Client Authentication Recommendations for Encrypted DNS |
| |
| | draft-tjjk-cared-00.txt |
| | Date: |
27/06/2024 |
| | Authors: |
Tommy Jensen, Jessica Krynitsky, Jeffrey Damick, Matt Engskow |
| | Working Group: |
Individual Submissions (none) |
|
For privacy reasons, encrypted DNS clients need to be anonymous to their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each peer wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept resolutions from encrypted DNS clients that are managed by the same enterprise. This requires mutual authentication. This document defines when using client authentication with encrypted DNS is appropriate, the benefits and limitations of doing so, and the recommended authentication mechanism(s) when communicating with TLS- based encrypted DNS protocols. |
| | BGP SR Policy Extensions for Weight Time Range |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. In the scenario where there are multiple segment list paths, traffic load balancing can be achieved based on the weight value assigned to each path. Typically, the weight value for each path is fixed. This document defines an extension of BGP SR Policy for setting the weight value for each path based on time range. |
| | 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. |
| |
|
| |
| | Additional Parameter sets for HSS/LMS Hash-Based Signatures |
| |
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | The BBS Signature Scheme |
| |
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs-of-knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages. |
| | Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks |
| |
|
The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. An SR-MPLS 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 traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes. |
| | An Overview of Network Slicing Efforts in The IETF |
| |
|
This document lists a set of slicing-related specifications that are being development within the IETF. This document is meant to provide an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent. |
| | Intel Profile for CoRIM |
| |
|
This document describes extensions to CoRIM that support Intel- specific Attester implementations and corresponding Endorsements and Reference Values. Multiple Evidence formats are anticipated, but all anticipated Evidence can be mapped to Reference Values expressions based on CoRIM and the CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers may use this profile to author mainifests containing Reference Values and Endorsements. Verifiers will recognize this profile by it's profile identifier and implement support for the extentions defined or may identify a suitable Verifier, or will refuse to process inputs. |
| | Research Agenda for a Post-Quantum DNSSEC |
| |
|
This document describes a notional research agenda for collaborative multi-stakeholder research related to a future post-quantum DNSSEC ecosystem. It is inspired by the anticipation that adoption of Post- Quantum signature algorithms will have enough operational impact on DNSSEC that either DNS protocol enhancements will be needed, or DNS will move away from UDP as the prevalent DNS transport, or a combination of both will be needed. Some members of the DNS technical community have even suggested evaluating alternatives to DNSSEC and potentially adopting an alternative protocol or practices to assure the integrity of DNS responses. Given the potential impact of such changes on the DNS ecosystem, the authors believe collaborative multi-stakeholder research into the impact of proposed changes should be performed to inform adoption and standardization activities. |
| | Flow Metadata for Collaborative Host/Network Signaling |
| |
| | draft-rwbr-sconepro-flow-metadata-02.txt |
| | Date: |
26/06/2024 |
| | Authors: |
Sridharan Rajagopalan, Dan Wing, Mohamed Boucadair, Tirumaleswar Reddy.K, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. |
| | MPLS Network Actions for Transporting In Situ Operations,Administration,and Maintenance (IOAM) Data Fields and Direct Exporting |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document defines MPLS Network Actions for transporting IOAM data fields as well as direct exporting them. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) framework. |
| | OpenPGP Signature Salt Notation |
| |
|
This document defines the "salt" Notation Name for OpenPGP version 4 signatures. This can be used to salt version 4 signatures in a backwards-compatible way. |
| | Robust and Privacy-Preserving Delivery Service |
| |
|
This document describes a federated MLS Delivery Service (DS) for use in the More Instant Messaging Interoperability (MIMI) protocol. The DS provides for the delivery of KeyPackages, Welcome messages, and group handshake/application messages. |
| | Deprecating Obsolete Key Exchange Methods in TLS 1.2 |
| |
|
This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. |
| |
|
| |
| | BPF Instruction Set Architecture (ISA) |
| |
|
eBPF (which is no longer an acronym for anything), also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as an operating system kernel. This document specifies the BPF instruction set architecture (ISA). |
| | A YANG Data Model for Optical Transport Network Topology |
| |
| | draft-ietf-ccamp-otn-topo-yang-19.txt |
| | Date: |
25/06/2024 |
| | Authors: |
Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. |
| | 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. |
| | Multicast On-path Telemetry using IOAM |
| |
|
This document specifies the solutions to meet the requirements of on- path telemetry for multicast traffic using In-situ OAM. While In- situ OAM is advantageous for multicast traffic telemetry, some unique challenges are present. This document provides the solutions based on the In-situ OAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | SRv6 for Inter-Layer Network Programming |
| |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. New SRv6 behaviors used for steering packets to underlay links or connections are defined, and the applicability of these SRv6 behaviors in typical inter-layer network programming scenarios is illustrated. |
| | Flow Measurement in IPv6 Network |
| |
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. |
| | SRPM Path Consistency over SRv6 |
| |
|
TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light. |
| | Distributed Flow Measurement in IPv6 |
| |
|
In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller. |
| | MPLS Network Action for Entropy |
| |
|
Load balancing is a powerful tool for engineering traffic across a network and has been successfully used in MPLS as described in "The Use of Entropy Labels in MPLS Forwarding". With the emergence of MPLS Network Actions (MNA), there is signficant benefit in being able to invoke the same load balancing capabilities within the more general MNA infrastructure. This document describes a network action for entropy to be used in conjunction with [I-D.ietf-mpls-mna-hdr]. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-jags-mpls-ps-mna-hdr-03.txt |
| | Date: |
25/06/2024 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack based on In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution". MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet or perform user-defined operations. This solution document addresses the Post-stack network action and Post-stack data (PSD) specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "MPLS Network Actions (MNA) Framework". |
| | MPLS Network Actions for Network Resource Partition Selector |
| |
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provided the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. |
| | UAS Serial Numbers in DNS |
| |
|
This document describes a way Uncrewed Aerial System (UAS) Serial Numbers are placed into and retrieved from the Domain Name System (DNS). This is to directly support DRIP-based Serial Numbers. |
| | VESPER - VErifiable STI Personas |
| |
|
This document extends the STIR architecture by specifying the use of JSON Web Tokens (JWT) and Selective Disclosure JWT (SD-JWT) for representing persona related information intended to be the output of a Know Your Customer (KYC) or Know Your Business (KYB) type of vetting process. It defines entities called Vetting Agents (VA) that perform a vetting of persona related information and can issue a verifiable token bearing the VA signature, containing information that can be disclosed or selectively disclosed to an interested party. The Vetted Entity (VE) can hold this token in selectively disclosable forms to disclose specific information to the third parties. The vesper token enables the delivery and verification of information with privacy protecting mechanism in a complete, selective or zero knowledge manner specifically supported by the SD- JWT. This document also describes an API standard to be supported/ hosted by a Vetting Agent (VA), which allow vetted parties to present tokens proving their KYC/KYB conformance, and incorporates proof of possession to ensure the legitimacy of the entity presenting the token. |
| | YANG Data Models for Energy Saving Management |
| |
|
This document defines YANG modules for energy saving management at both device and network levels. Also, the document specifies a common module that is used independent of the model layer. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Inventory YANG Working Group mailing list (inventory-yang@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/inventory-yang/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-cwbgp-energy-saving-management. |
| | Redefining Secure Channel for ipv4only.arpa IPv6 Prefix Discovery |
| |
|
This document updates [RFC7050] to redefine the term "secure channel" and modify requirements for nodes and DNS64 servers to use more recent developments in DNS security. |
| | A YANG Data Model and RADIUS Extension for Policy-based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-05.txt |
| | Date: |
25/06/2024 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths |
| |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of the SR Policy. Additionally, this document updates RFC 8231 to allow stateful bring up of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). |
| | Protocol Numbers for SCHC |
| |
|
This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. |
| | A Profile for Autonomous System Provider Authorization |
| |
| | draft-ietf-sidrops-aspa-profile-18.txt |
| | Date: |
25/06/2024 |
| | Authors: |
Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. |
| |
|
| |
| | Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. |
| | EVPN Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-01.txt |
| | Date: |
24/06/2024 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| | Updates to the CDDL grammar of RFC 8610 |
| |
|
The Concise Data Definition Language (CDDL), as defined in RFC 8610 and RFC 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in CBOR or JSON. The present document updates RFC 8610 by addressing errata and making other small fixes for the ABNF grammar defined for CDDL there. |
| | BMP YANG Module |
| |
| | draft-ietf-grow-bmp-yang-04.txt |
| | Date: |
24/06/2024 |
| | Authors: |
Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise |
| | Working Group: |
Global Routing Operations (grow) |
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). |
| | Updated YANG Module Revision Handling |
| |
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. |
| | 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. |
| | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
|
This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It includes protocol extensions made as part of respecification effort for minor version 1. It obsoletes and replaces RFC5662. |
| | IGP Extensions for Deterministic Traffic Engineering |
| |
|
This document describes IGP extensions to support Traffic Engineering (TE) of deterministic routing, by specifying new information that a router can place in the advertisement of neighbors. This information describes additional details regarding the state of the network that are useful for deterministic traffic engineering path computations. |
| | Intent-Based Network Management in SRv6 Networks |
| |
|
This document describes secure network management in Segment Routing version six (SRv6) networks. It proposes a framework empowered with Intent-Based Networking (IBN). The Intent-Based Network Management (IBNM) in this document specifies an architectural framework with system components and interfaces. Also, this framework builds on Interface to Network Security Functions (I2NSF). |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis effort. It describes the structure and function of Access Control Lists within all minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs 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. Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was intended, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. In this document, the relationship among the multiple ACL models supported has changed. A core set of functionality, derived from a subset of that provided by the now-withdrawn draft POSIX ACLs is presented as the conceptual base of the feature set. Two additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft POSIX ACL model are presented as OPTIONAL extensions to that core. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts 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 for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Constrained Application Protocol (CoAP) over Bundle Protocol (BP) |
| |
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. |
| | An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems |
| |
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system like Kubernetes and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. |
| | Common Format and Media Type for Control-Character-Separated Values (CCSV) Files |
| |
|
This document establishes the format used for Control-Character- Separated Values (CCSV) files and registers the associated MIME type "text/ccsv". |
| | 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. |
| | Filter of Configuration Change Notifications |
| |
|
This document extends the YANG-Push notification subscription mechanism for on-change to reduce unnecessary reporting after an on- change YANG-Push notification is generated. |
| |
|
| |
| | The Deprecation HTTP Header Field |
| |
|
The Deprecation HTTP response header field is used to signal to consumers of a resource (in the sense of [URI]) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional information about planned or existing deprecation, and possibly ways in which clients can best manage deprecation. |
| | Clarification and enhancement of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-10.txt |
| | Date: |
23/06/2024 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. Moreover, it provides new convenient and straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows specifying a subject Distinguished Name (DN). |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-19.txt |
| | Date: |
23/06/2024 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. |
| | Randomized and Changing MAC Address Use Cases |
| |
| | draft-ietf-madinas-use-cases-10.txt |
| | Date: |
23/06/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. |
| | Transient Hiding of Hop-by-Hop Options |
| |
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. |
| | Segment Routing Policy Extension for NRP |
| |
|
Network Resource Partition (NRP), which is a subset of the resources and associated policies in the underlay network. In networks with multiple NRPs, an SR Policy can be associated with a particular NRP. This document describes how the SR Policy extension for associated NRP and the operational mechanisms function together. |
| |
|
| |
| | Detecting Unwanted Location Trackers Accessory Protocol |
| |
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. |
| | rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP |
| |
| | draft-irtf-iccrg-rledbat-08.txt |
| | Date: |
22/06/2024 |
| | Authors: |
Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen Balasubramanian |
| | Working Group: |
Internet Congestion Control (iccrg) |
|
This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). |
| | Extensible In-band Processing (EIP) Architecture and Framework |
| |
| | draft-eip-arch-04.txt |
| | Date: |
22/06/2024 |
| | Authors: |
Stefano Salsano, Hesham ElBakoury, Diego Lopez |
| | Working Group: |
Individual Submissions (none) |
|
Extensible In-band Processing (EIP) extends the functionality of the IPv6 protocol considering the needs of future Internet services / 6G networks. This document discusses the architecture and framework of EIP. Two separate documents respectively analyze a number of use cases for EIP and provide the protocol specifications of EIP. |
| | Interconnecting domains with IBGP |
| |
|
This document relaxes the recommendations specified in BGP/MPLS IP Virtual Private Networks (VPNs) and BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) allowing the building of Inter-domain L3VPN architecture with internal BGP. |
| | Mtrace2 L2 Extensions: Traceroute Facility for Layer 2 Multicast |
| |
|
This document describes extensions to IP multicast traceroute facility, named Mtrace2 version 2 (Mtrace2), to include traced path for Layer 2 multicast. Mtrace2 allows tracing the path from Last-Hop Router (LHR) to a source. Tracing the Layer 2 path from LHR till the actual receivers requires special implementations on the part of switches in the Layer 2 path. This specification describes the required functionality in multicast routers and switches. This feature functions along with the Layer 2 multicast protocols like IGMP (Internet Group Management Protocol) Snooping and MLD(Multicast Listener Discovery) Snooping. |
| | A YANG Data Model for Virtual Network (VN) Operations |
| |
| | draft-ietf-teas-actn-vn-yang-29.txt |
| | Date: |
22/06/2024 |
| | Authors: |
Young Lee, Dhruv Dhody, Daniele Ceccarelli, Igor Bryskin, Bin Yoon |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it was a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| | Establishing Local DNS Authority in Validated Split-Horizon Environments |
| |
|
When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver. DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains. |
| | AS Path Prepending |
| |
| | draft-ietf-grow-as-path-prepending-13.txt |
| | Date: |
20/06/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. |
| | 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. |
| | Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data |
| |
|
This document presents use cases that have a common feature in that they may be addressed by encoding network action indicators and associated ancillary data within MPLS packets. There are interest in extending the MPLS data plane to carry such indicators and ancillary data to address the use cases that are described in this document. The use cases described in this document are not an exhaustive set, but rather the ones that are actively discussed by members of the IETF MPLS, PALS, and DetNet working groups. |
| | 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. |
| | Extended relation information for Semantic Definition Format (SDF) |
| |
|
The Semantic Definition Format (SDF) base specification defines set of basic information elements that can be used for describing a large share of the existing data models from different ecosystems. While these data models are typically very simple, such as basic sensors definitions, more complex models, and in particular bigger systems, benefit from ability to describe additional information on how different definitions relate to each other. This document specifies an extension to SDF for describing complex relationships in class level descriptions. This specification does not consider instance- specific information. |
| | Update to Automatic Bandwidth Adjustment procedure of Stateful PCE |
| |
|
Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to explicitly remove an attribute identified by the sub- TLV. This document updates RFC 8733 by defining the behaviour to explicitly remove an attribute. |
| | Integrating the Alternate-Marking Method into In Situ Operations,Administration,and Maintenance (IOAM) |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. |
| | Philatelist,YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases |
| |
|
Timestamped telemetry data is collected en masse today. Mature tools are typically used, but the data is often collected in an ad hoc manner. While the dashboard graphs look great, the resulting data is often of questionable quality, not well defined, and hard to compare with seemingly similar data from other organizations. This document proposes a standard, extensible, cross domain framework for collecting and aggregating timestamped telemetry data in a way that combines YANG, metadata and Time Series Databases to produce more transparent, dependable and comparable results. This framework is implemented in the Network Controller layer, but is rooted in data that is collected from all kinds of Network Elements and related systems. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification with efficient fragmentation and reassembly procedures. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. |
| | Deterministic Source Route Header |
| |
|
This document introduces a new IPv6 Routing Header that is a variant of RPL Source Route Header (SRH) and used for deterministic forwarding wihch is generally a strict explicit path. This Routing Header contains the decoupled topology instructions and deterministic forwarding resource indications. The target is low cost of encapasultion and less amount of allocated SIDs. |
| | Timeslot Queueing and Forwarding (TQF) Control Plane |
| |
|
To achive DetNet QoS in IP/MPLS network and meet the large scaling requirements, timeslot queueing and forwarding (TQF) mechanism for enhancing TAS is introduced. This document describes the controller plane function (CPF) for TQF mechanism. |
| | Modelling of Optical Pluggables in Packet Over Optical Network |
| |
|
This draft outlines the modeling of optical pluggables within a host packet device in the context of a packet over optical network. The model encompasses all pertinent properties of the pluggable for various packet over optical use cases and is partitioned into three primary areas: the optical media interface, the electrical plug to host interconnect, and the physical equipment of the pluggable. Included in the model are representations of configuration, states, and telemetry data, as well as of profiles and coherent plug capabilities. Emphasizing the importance of considering both vendor- agnostic and vendor-specific attributes in modeling coherent pluggables. Drawing from existing models in IETF, OpenConfig, ITU-T, OIF, and TAPI, this model offers enhanced uniform structuring and naming. Additionally, it provides insight into the mapping to plug interface structures defined in CMIS. This draft introduces the concpet of "Coherent Pluggable Manifest", where a represents the capabilities of a type&version of pluggable, maintained in a public repository of all pluggables. This document also covers gap analysis of current IETF drafts and other SDOs on coherent pluggables attributes and provides the complete lifecycle of a coherent pluggable from operators' approval through viability assessment to deployment. |
| | Fake Draft for Testing |
| |
|
This draft is for testing porpoises only. |
| |
|
| |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-07.txt |
| | Date: |
19/06/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. |
| | A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane |
| |
|
This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. |
| | Media Type Suffixes |
| |
|
This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to provide additional clarifications on how to interpret and register media types with suffixes. |
| | Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure |
| |
|
This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, this document discusses those applications that run on devices having different form factors (such as different physical sizes and shapes) and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. This document discusses the expected behavior of XR applications which can be used to manage the traffic. In addition, the document discusses the service requirements of XR applications to be able to run on the network. |
| | An Update on Milestones |
| |
|
As mandated in RFC 2418, working group charters currently contain milestones. However, these milestones are often sufficiently out of date that they no longer provide value. This document makes milestones optional and allows more discretion on their dates. It updates RFC 2418. |
| | IETF Plenary List Management Procedures |
| |
|
This memo provides a procedure and authority to address inappropriate behavior on IETF plenary lists. It obsoletes RFC 3683 and updates RFC 9245. |
| | A method to store information via email and ensure the verification of the data and the identification of the version |
| |
|
This document describes a method to store information via email and to ensure the verification of the data and identification of the version. As a long-established way of communicating and sharing information and knowledge, email is at the heart of the V verification system (V-VS). |
| | Deterministic Networking SRv6 Data Plane |
| |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. |
| | Deterministic Networking specific SID |
| |
|
Replication, Elimination and Ordering functions of the DetNet Architecture require packet sequence information (i.e., sequence number) to provide service protection by the DetNet service sub- layer. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed on packets of DetNet flows to support the specific service protection treatment. |
| | A membership proof extensions for the Messaging Layer Security (MLS) Protocol |
| |
|
This document describes an MLS safe extension that members of a group can use to assert membership to non-members. 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://rohanmahy.github.io/mls-member-proof/draft-mahy-member- proof.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mls-member-proof/. Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/mls-member-proof. |
| | On-path Telemetry YANG Data Model |
| |
|
This document proposes a YANG data model for monitoring on-path telemetry information. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the on-path hybrid measurement methods considered in this document. |
| | Internet Control Message Protocol (ICMP): Standards and Operational Experience |
| |
|
The Internet Control Message Protocol (ICMP) can be used to exchange control information between hosts. This document summarizes ICMP standards and operational experience. The purpose of this document is to be used as a reference. A document that mentions ICMP can reference this document rather than repeating portions of its content. |
| | STAMP Extensions for DetNet |
| |
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. |
| | Network Time Protocol Version 5 |
| |
|
This document describes the version 5 of the Network Time Protocol (NTP). |
| | PCEP Extension for Layer 2 (L2) Flow Specification |
| |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| |
|
| |
| | JWS signed Voucher Artifacts for Bootstrapping Protocols |
| |
|
[I-D.draft-ietf-anima-rfc8366bis] defines a digital artifact called voucher as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS. In addition to explaining how the format is created, the "application/voucher-jws+json" media type is registered and examples are provided. |
| | Automatic Peering for SIP Trunks |
| |
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. |
| | COSE Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. |
| | System-defined Configuration |
| |
|
This document defines how a management client and management server handle YANG-modeled configuration data that is instantiated 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 expose system-defined configuration. This document updates RFC 6241, RFC 8040, RFC 8342, and RFC 8526. |
| | remoteStorage |
| |
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. |
| | Problems and Requirements of Addressing in Integrated Space-Terrestrial Network |
| |
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. |
| | Usecases of SRv6 Based Computing Interconnection Network |
| |
|
The requirements of computing interconnection are increasingly attracting the attention of service providers. They have been thinking about how to leverage their network advantages to provide integrated networking and computing services. This document describes some scenarios of using SRv6 based network technology which can partially meet the service requirement of computing interconnection. |
| | YANG model for NETCONF Event Notifications |
| |
|
This document defines the structure of NETCONF Event Notification in a YANG model to be used in NETCONF environments. The definition of this YANG model allows the encoding of NETCONF Event Notifications in YANG compatible encodings such as JSON and CBOR. |
| | OAuth Status Assertions |
| |
|
Status Assertion is a signed object that demonstrates the validity status of a digital credential. These assertions are periodically provided to holders, who can present these to verifier along with the corresponding digital credentials. The approach outlined in this document makes the verifier able to check the non-revocation of a digital credential without requiring to query any third-party entities. |
| | ICMP extension to include underlay information |
| |
|
Network operators operating overlay networks require the ability to identify hops in an underlay network when traceroute in the overlay. This document defines an ICMP Error extension message to carry the underlay error information to the overlay network endpoint. |
| | Secure Asset Transfer (SAT) Interoperability Architecture |
| |
| | draft-ietf-satp-architecture-05.txt |
| | Date: |
18/06/2024 |
| | Authors: |
Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. |
| | Zero Checksum for the Stream Control Transmission Protocol |
| |
|
The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP already provides the same or a higher level of data integrity, computing this checksum does not provide any additional protection, but does consume computing resources. This document provides a simple extension allowing SCTP to save these computing resources by using zero as the checksum in a backwards compatible way. It also defines how this feature can be used when SCTP packets are encapsulated in Datagram Transport Layer Security (DTLS) packets. |
| |
|
| |
| | 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. |
| | HTTP Cache Groups |
| |
|
This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored response with one or more opaque strings. |
| | Allowing Community Registrations in the Standards Tree |
| |
|
Over time, it has become clear that there are media types which have the character of belonging in the standards tree (because they are not associated with any one vendor or person), but are not published by a standards body. This draft suggests an update to [RFC6838] to allow their registration. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-07.txt |
| | Date: |
17/06/2024 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Action (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet or perform user- defined operations. This solution document specifies In-stack network action and In-stack data (ISD) specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "MPLS Network Actions (MNA) Framework". |
| | MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) |
| |
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. |
| | Security for the NFSv4 Protocols |
| |
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the ACL feature, will be specified in a separate document. 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 documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881, |
| | Juniper's Secure Vector Routing (SVR) |
| |
| | draft-menon-svr-06.txt |
| | Date: |
17/06/2024 |
| | Authors: |
Abilash Menon, Patrick MeLampy, Michael Baj, Patrick Timmons, Hadriel Kaplan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Juniper's Secure Vector Routing (SVR). SVR is an overlay inter-networking protocol that operates at the session layer. SVR provides end-to-end communication of network requirements not possible or practical using network header layers. SVR uses application layer cookies that eliminate the need to create and maintain non-overlapping address spaces necessary to manage network routing requirements. SVR is an overlay networking protocol that works through middleboxes and address translators including those existing between private networks, the IPv4 public internet, and the IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases and improves security at the networking routing plane. SVR eliminates the need for encapsulation and decapsulation often used to create non-overlapping address spaces. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | Key Transparency |
| |
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. In addition to distributing public keys, it can also be applied to ensure that a group of users agree on a shared value or to keep tamper-evident logs of security-critical events. |
| | Digital Credential Profiles Best Current Practices |
| |
|
Digital Credentials are frequently modeled on documents, forms, and messages that enable a holder to prove they have attributes that are acceptable to a verifier. This document provides guidance to verifiers enabling them to describe their requirements such that they can be translated into digital credential profiles. |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | Selective Disclosure CWTs (SD-CWT) |
| |
|
This document describes a data minimization technique for use with CBOR Web Token (CWT) [RFC8392]. The approach is based on SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt], with changes to align with CBOR Object Signing and Encryption (COSE). This document updates RFC8392. |
| | Segment Routing based Solution for Hierarchical IETF Network Slices |
| |
|
This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. |
| | RDAP Simple Redaction |
| |
|
This document defines a simple redaction extension for the Registration Data Access Protocol (RDAP). |
| | RIFT Applicability and Operational Considerations |
| |
| | draft-ietf-rift-applicability-17.txt |
| | Date: |
17/06/2024 |
| | Authors: |
Yuehua Wei, Zheng Zhang, Dmitry Afanasiev, Pascal Thubert, Tony Przygienda |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document discusses the properties, applicability and operational considerations of RIFT in different network scenarios. It intends to provide a rough guide how RIFT can be deployed to simplify routing operations in Clos topologies and their variations. |
| | Distribute SRv6 Locator by DHCP |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through DHCPv6. |
| |
|
| |
| | Cumulative DMZ Link Bandwidth and load-balancing |
| |
| | draft-ietf-bess-ebgp-dmz-05.txt |
| | Date: |
16/06/2024 |
| | Authors: |
MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, Reshma Das |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor-level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers. |
| | Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. |
| | BGP Dissemination of Flow Specification Rules for Tunneled Traffic |
| |
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. |
| | BGP SR Policy Extensions for metric |
| |
|
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. |
| | Support of Versioning in YANG Notifications Subscription |
| |
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| |
|
| |
| | Use of Reliable Transport in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
The Internet Key Exchange protocol version 2 (IKE2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports, so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g. when post-quantum algorithms are employed) while avoiding performance problems which arise when TCP is used for IPsec. |
| | Paired MLS - PCS in Limited Modes |
| |
|
This document describes the Paired Messaging Layer Security (MLS) extension that improves Post Compromise Security for devices that are unable to self-update using a trusted paired device. |
| | Security and Privacy Implications of 3GPP AI/ML Networking Studies for 6G |
| |
|
This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) networking. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. |
| | Gap Analysis,Problem Statement,and Requirements in AI Networks |
| |
|
This document provides the gap analysis of AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | A OSF Framework for Artificial Intelligence (AI) Network |
| |
|
This document describes a framework for Artificial Intelligence (AI) network, Particularly, the document identifies a set of AI network components, describes their interactions, and exemplifies the workflow of the control and data planes. |
| | Draft DULT Threat Model |
| |
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted location trackers must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, will define what is in and out of scope for the unwanted location tracking protocols, and will provide some design considerations for implementation of protocols to detect unwanted location tracking. |
| | Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations |
| |
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. |
| | A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks |
| |
| | draft-ietf-teas-enhanced-vpn-20.txt |
| | Date: |
14/06/2024 |
| | Authors: |
Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka, Young Lee |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document describes the framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). An NRP represents a subset of network resources and associated policies in the underlay network. NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work. |
| |
|
| |
| | Internet Message Format |
| |
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism that enable adaptive subscription to YANG notifications. The periodic update interval for the stream can be set adaptively. Applying adaptive subscription allows publishers to automatically adjust the period and volume of telemetry data sent to receivers. |
| | Adaptive IPv4 Address Space |
| |
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. |
| | Use cases for DIS Modifications |
| |
|
This document presents use-cases which call for DIS flags and options modifications. |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, RPs or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM-SD deployments. |
| | Non-source-routed Multicast in SR Networks |
| |
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. |
| | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. |
| | Internet Group Management Protocol,Version 3 |
| |
|
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. It is a revised version of the specification to include clarifications and fixes for errata in RFC 3376 and is backwards compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. |
| | IANA Considerations for Internet Group Management Protocols |
| |
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols. |
| |
|
| |
| | Limits on Sending and Processing IPv6 Extension Headers |
| |
|
This specification defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers, thereby increasing the feasibility of deployment of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. |
| | The OPAQUE Augmented PAKE Protocol |
| |
| | draft-irtf-cfrg-opaque-16.txt |
| | Date: |
12/06/2024 |
| | Authors: |
Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | Algorithm Related IGP-Adjacency SID Advertisement |
| |
|
Segment Routing architecture supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. Two standard algorithms are defined in the segment routing architecture: SPF and Strict-SPF. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement. |
| | Egress Validation in Label Switched Path Ping and Traceroute Mechanisms |
| |
|
The MPLS ping and traceroute mechanisms, as described in [RFC8029] and the related extensions for Segment Routing (SR) defined in [RFC8287], is highly valuable for validating control plane and data plane synchronization. In certain environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A straightforward MPLS ping and traceroute mechanism allows traversing any path without validating the control plane state. [RFC8029] supports this mechanism with the Nil Forwarding Equivalence Class (FEC). The procedures outlined in [RFC8029] is primarily applicable when the Nil FEC is used as an intermediate FEC in the label stack. However, challenges arise when all labels in the label stack are represented using the Nil FEC. This document introduces a new Type-Length-Value (TLV) as an extension to the existing Nil FEC. It describes MPLS ping and traceroute procedures using the Nil FEC with this extension to address and overcome these challenges. |
| | Merkle Tree Ladder (MTL) Mode Signatures |
| |
|
This document provides an interoperable specification for Merkle tree ladder (MTL) mode, a technique for using an underlying signature scheme to authenticate an evolving series of messages. MTL mode can reduce the signature scheme's operational impact. Rather than signing messages individually, the MTL mode of operation signs structures called "Merkle tree ladders" that are derived from the messages to be authenticated. Individual messages are then authenticated relative to the ladder using a Merkle tree authentication path and the ladder is authenticated using the public key of the underlying signature scheme. The size and computational cost of the underlying signatures are thereby amortized across multiple messages, reducing the scheme's operational impact. The reduction can be particularly beneficial when MTL mode is applied to a post-quantum signature scheme that has a large signature size or computational cost. As an example, the document shows how to use MTL mode with SPHINCS+ (and the SLH-DSA subset specified in the draft FIPS 205), the stateless hash-based signature scheme selected by NIST for standardization. Like other Merkle tree techniques, MTL mode's security is based only on cryptographic hash functions, so the mode is quantum-safe based on the quantum-resistance of its cryptographic hash functions. |
| |
|
| |
| | Properties of AEAD Algorithms |
| |
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group. |
| | Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax |
| |
|
This document specifies additions and amendments to RFCs 7292 and 8018. It obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. |
| | OSPF-GT (Generalized Transport) |
| |
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. |
| | More Instant Messaging Interoperability (MIMI) message content |
| |
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| | OpenPGP Web Key Directory |
| |
|
This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. |
| | Secure Element for TLS Version 1.3 |
| |
|
This draft presents ISO7816 interface for TLS1.3 stack running in secure element. It presents supported cipher suites and key exchange modes, and describes embedded software architecture. TLS 1.3 is the de facto security stack for emerging Internet of Things (IoT) devices. Some of them are constraint nodes, with limited computing resources. Furthermore cheap System on Chip (SoC) components usually provide tamper resistant features, so private or pre shared keys are exposed to hacking. According to the technology state of art, some ISO7816 secure elements are able to process TLS 1.3, but with a limited set of cipher suites. There are two benefits for TLS-SE; first fully tamper resistant processing of TLS protocol, which increases the security level insurance; second embedded software component ready for use, which relieves the software of the burden of cryptographic libraries and associated attacks. TLS-SE devices may also embed standalone applications, which are accessed via internet node, using a routing procedure based on SNI extension. |
| | Key Transparency Protocol |
| |
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. |
| | A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits |
| |
|
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to Attachment Circuits (ACs) that are created using the AC service ("ietf-ac-svc") and network ("ietf-ac-ntw") models. |
| | 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. |
| | RPKI Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| | IETF Network Slice Application in 3GPP 5G End-to-End Network Slice |
| |
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. |
| |
|
| |
| | OTN Tunnel YANG Model |
| |
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. |
| | JMAP for Contacts |
| |
|
This document specifies a data model for synchronising contacts data with a server using JMAP. |
| | Performance Measurement for Segment Routing Networks with MPLS Data Plane |
| |
| | draft-ietf-mpls-rfc6374-sr-11.txt |
| | Date: |
06/06/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. |
| | Cisco's CoAP Simple Management Protocol |
| |
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. |
| | A SAVI Solution for WLAN |
| |
|
This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. |
| | The RFCXML version 3 Vocabulary as Implemented |
| |
|
This document describes the RFCXML version 3 vocabulary as implemented in tools used by the RFC Production Center at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home page at . Source code and issues list for this draft can be found at . |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-06.txt |
| | Date: |
06/06/2024 |
| | Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| | Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. |
| |
|
| |
| | Passive DNS - Common Output Format |
| |
|
This document describes a common output format of Passive DNS Servers that clients can query. The output format description also includes a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. |
| | Semantic Definition Format (SDF): Mapping files |
| |
|
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. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation. |
| | An sdfType for Links |
| |
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). |
| | Payload Protocol Identifier based Fragmentation and Reassembly for the Stream Control Transmission Protocol |
| |
|
This document describes a method for the Stream Control Transmission Protocol (SCTP) allowing the upper layer to perform fragmentation, reassembly, and interleaving of large ordered user messages by using the payload protocol identifier (PPID). According to the base specification supporting fragmentation of large user messages is optional. And even if an SCTP implementation supports fragmentation, interleaving of user messages is not supported by the base specification. |
| | A YANG Data Model for Open Shortest Path First (OSPF) Topology |
| |
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | No-Vary-Search |
| |
|
A proposed HTTP header field for changing how URL search parameters impact caching. 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://jeremyroman.github.io/http-no-vary-search/draft-wicg-http-no- vary-search.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wicg-http-no-vary-search/. Source for this draft and an issue tracker can be found at https://github.com/jeremyroman/http-no-vary-search. |
| | Dynamic QoS Mechanism |
| |
|
This document describes a dynamic QoS (Quality of Service) mechanism. |
| | Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a generic mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other to-be-defined identifier that can be allocated and managed by the PCE. |
| |
|
| |
| | BGP Based Multicast |
| |
| | draft-ietf-bess-bgp-multicast-08.txt |
| | Date: |
03/06/2024 |
| | Authors: |
Zhaohui Zhang, Lenny Giuliano, Keyur Patel, IJsbrand Wijnands, Mankamana Mishra, Arkadiy Gulko |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multicast trees. |
| | BGP Extensions for BIER |
| |
| | draft-ietf-bier-idr-extensions-11.txt |
| | Date: |
03/06/2024 |
| | Authors: |
Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain per-tree multicast states. Some BIER-specific information and state, which are only in proportion to the network but not per-tree, do need to be advertised, calculated, and maintained. This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisement. |
| | 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. |
| | Reverse Traceroute |
| |
|
Only very few troubleshooting tools exist, that universally work on the public internet. Ping and traceroute are the ones that are most frequently used, when issues arise that are outside the user's administrative reach. Both perform quite basic checks. Ping can only confirm basic reachability of an interface. Traceroute can enumerate routers in the forward direction of a path but remains blind to the reverse path. In this memo, ICMP extensions are defined, that allow to build a reverse traceroute tool for the public internet. |
| | Post-Quantum Cryptography Recommendations for Internet Applications |
| |
|
Post-quantum cryptography brings some new challenges to applications, end users, and system administrators. This document describes characteristics unique to application protocols and best practices for deploying Quantum-Ready usage profiles for applications using TLS. |
| | Internet Control Message Protocol (ICMPv6) Loopback |
| |
|
This document defines ICMPv6 Loopback, which enables a two-way packet exchange that can be used for probing and for diagnostic purposes. ICMPv6 Loopback is similar to ICMPv6 Echo, except that after a Loopback Request is sent, its corresponding Reply includes as much of the IPv6 Loopback Request packet as possible, including the IPv6 header and IPv6 extension headers and options if they are present. |
| | BGP Flow Specification Version 2 - More IP Actions |
| |
|
The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft suggests additional IP actions for Flow Specification FSv2 in Extended Communities and Community path attribute. |
| | IPv6 Over Bluetooth for Power Affluent Devices |
| |
| | draft-elkins-v6ops-ipv6blt-00.txt |
| | Date: |
03/06/2024 |
| | Authors: |
Nalini Elkins, Mohit Tahiliani, Rakshith Mohan, Shrinidhi Nidamboor, 84 108 |
| | Working Group: |
Individual Submissions (none) |
|
IPv6 over Bluetooth enables devices to communicate using the IPv6 protocol stack over Bluetooth wireless connections, expanding the range of networking options available to devices with Bluetooth capability. RFC 7668 and RFC 9159 describe IPv6 over Bluetooth for Bluetooth Low Energy devices. However, the potential of this technology has yet to be fully explored. This document proposes using this technology for power affluent devices with optional header compression and discusses some use cases. |
| | RTCP feedback Message for Loss Notification |
| |
|
Real-time media streams that use RTP, use multiple mechanisms to recover from packet and frame loss. Sender to recover frame loss effectively, it can use information on the last frame receiver successfully decoded and latest packet it received on network. This document describes an RTP Control Protocol (RTCP) feedback message intended to notify the sender with loss details. |
| | OAuth 2.0 Security Best Current Practice |
| |
|
This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFC 6749, RFC 6750, and RFC 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. |