|
|
| |
| Controller Based BGP Multicast Signaling |
|
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. |
| OSPF YANG Model Augmentations for Additional Features - Version 1 |
|
|
This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 8920, and OSPF Flexible Algorithm. |
| Challenges and Opportunities in Management for Green Networking |
|
| draft-irtf-nmrg-green-ps-02.txt |
| Date: |
30/12/2023 |
| 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 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. Methods to make networking technology itself "greener" and to manage and operate networks in ways that reduces their environmental footprint without impacting their utility therefore 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. |
| Framework for Rule-based International Cyberspace Governance |
|
| draft-hanliu-ricg-01.txt |
| Date: |
30/12/2023 |
| Authors: |
Han Liu, Jilong Wang, Chengyuan Zhang, Pardis Tehrani, Ji Ma |
| Working Group: |
Individual Submissions (none) |
|
Cyberspace involves politics, economy, culture, and technology; it engages governments, international organizations, Internet companies, technology communities, civil society, and citizens, forming an integrated, organic body. In a word, cyberspace is the online version of a community with a shared future for mankind. This memo tries to outline a new framework for rule-based international cyberspace governance regime in the context of IPv6 application, which looks into the future international cooperation of cyberspace governance. |
| Sloppy Topology Updates for ad-hoc Routing Protocols (STURP) |
|
| draft-lou-manet-sturp-01.txt |
| Date: |
30/12/2023 |
| 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. |
|
|
| |
| BMP YANG Module |
|
| draft-ietf-grow-bmp-yang-03.txt |
| Date: |
29/12/2023 |
| 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). |
| 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. |
|
|
| |
| Cumulative DMZ Link Bandwidth and load-balancing |
|
| draft-ietf-bess-ebgp-dmz-04.txt |
| Date: |
28/12/2023 |
| Authors: |
MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura |
| 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. |
| Equal-Cost Multipath Considerations for BGP |
|
|
BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features. |
| 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. |
| 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. |
| Ethernet over HTTPS Protocol |
|
|
This document defines a protocol for encapsulating Ethernet frames over HTTPS, allowing secure communication between a client and internal web servers. The protocol includes authentication using strong API keys encrypted with the server's public key. The communication is secured using TLS for privacy and integrity. |
|
|
| |
| 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. |
| 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. |
| Cycle Mapping Learning Method for Scaling DetNet |
|
|
The scaling DetNet (Deterministic Networking) technology based on cyclic queuing and scheduling is expected to solve the scalability problem of DetNet, and is hoped to extend the adaptive domain of DetNet to wide area network or even backbone network. One of the keys of this technology is to accurately obtain the cyclic mapping relationship between adjacent nodes, based on which DetNet packets can be end-to-end deterministically forwarded . This draft proposes a method for nodes to learn the cycle mapping relationship through sending learning messages. |
| vCard Credentials |
|
|
vCard is a file format for digital business cards. This document enables vCards to be used as a transport for digital credentials. |
| Secure Shell Key Exchange Method Using Hybrid Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512 |
|
|
This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on Classic McEliece (mceliece6688128) and X25519 with SHA-512. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-ssh-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-mceliece. |
|
|
| |
| 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. But 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.. |
| 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. |
| A Framework for NRP-based Enhanced Virtual Private Network |
|
| draft-ietf-teas-enhanced-vpn-17.txt |
| Date: |
25/12/2023 |
| 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 NRP-based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and adds 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. |
|
|
| |
| Network-Hexagons:Geolocation Mapping Network Based On H3 and LISP |
|
| draft-ietf-lisp-nexagon-52.txt |
| Date: |
24/12/2023 |
| Authors: |
Sharon Barkai, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Jordi Paillisse, Dino Farinacci |
| Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This specification describes functionality of LISP Nexagon networks. The network shares a joint vision of any number of producing sources, fleets, drones, and satellite, with any number of consuming clients, maps, GIS, and path planning copilots. Specifically it outlines: - joint-vision tiled enumeration geolocation language channels - addressing change notifications, overlaps, points of view, - freshness, privacy, localization, seamless context-switching, - via stateful driving of stateless models by EID location agents Safety applications of this network are: 1. Safety on-road: blockages & hazards beyond line of sight 2. Safety off-road: traffic-ability and varying risk degrees 3. Safety during disasters: fires, floods, snow, abrupt change The use of LISP enables the network to function securely uninterrupted while vision producers and consumers are constantly moving due to the connectivity-anchoring properties of LISP EIDs. Since EIDs are logical being based on mapping-system, it provides semantic-anchoring as well. Semantic joint vision consolidation uses H3 EID unicast and multicast. |
| Generic Fault-Avoidance Routing Protocol for Data Center Networks |
|
| draft-sl-rtgwg-far-dcn-21.txt |
| Date: |
24/12/2023 |
| Authors: |
Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish |
| Working Group: |
Individual Submissions (none) |
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. |
| 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. |
| MISP galaxy format |
|
|
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing. |
| MISP object template format |
|
|
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format. |
| JSON Web Token (JWT) Embedded Tokens |
|
|
This specification defines a mechanism for embedding tokens into a JWT token. The JWT token and the embedded tokens are issued by one ore more issuers. |
| 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. |
|
|
| |
| YANG Schema Item iDentifier (YANG SID) |
|
| draft-ietf-core-sid-24.txt |
| Date: |
22/12/2023 |
| Authors: |
Michel Veillette, Alexander Pelov, Ivaylo Petrov, Carsten Bormann, Michael Richardson |
| Working Group: |
Constrained RESTful Environments (core) |
|
YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (–24) is intended to address the remaining // IESG comments. |
| Refresh-interval Independent FRR Facility Protection |
|
|
RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. |
| MSYNC |
|
| draft-bichot-msync-15.txt |
| Date: |
22/12/2023 |
| Authors: |
Sophie Bale, Remy Brebion, Guillaume Bichot |
| Working Group: |
Individual Submissions (none) |
|
This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. |
| 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. |
| Considerations for SRv6 across Untrusted Domain |
|
|
Segment Routing operates within a trusted domain. There are some scenarios in which the whole SRv6 domain is separated by untrusted domain and SRv6 packets need to traverse it. This document describes some use cases of SRv6 across untrusted domain, and proposes a solution using IPSec technology. |
| NTS extensions for enabling pools |
|
| draft-venhoek-nts-pool-00.txt |
| Date: |
22/12/2023 |
| Authors: |
David Venhoek, Folkert de Vries, Marc Schoolderman |
| Working Group: |
Individual Submissions (none) |
|
The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple downstream servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. |
| 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 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. |
| Extensible In-band Processing (EIP) Architecture and Framework |
|
| draft-eip-arch-03.txt |
| Date: |
21/12/2023 |
| 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. |
| A Pre-Authentication Mechanism for SSH |
|
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| Internet Wall |
|
|
To be able to say the owner of two emails are same like pradeep@4a2e.online = pradeepan88@hotmail.com |
|
|
| |
| RTP Payload Format for Essential Video Coding (EVC) |
|
| draft-ietf-avtcore-rtp-evc-07.txt |
| Date: |
20/12/2023 |
| Authors: |
Shuai Zhao, Stephan Wenger, Youngkwon Lim |
| Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This document describes an RTP payload format for the Essential Video Coding (EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was developed by the Moving Picture Experts Group (MPEG). The RTP payload format allows for the packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets. The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. |
| BGP-LS Advertisement of TE Policy Performance Metric |
|
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| Detecting Unwanted Location Trackers |
|
|
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. |
| Analysis and Evaluation for TSN Queuing Mechanisms |
|
|
TSN technology standards developed in the IEEE 802.1TSN Task Group define the time-sensitive mechanism to provide deterministic connectivity through IEEE 802 networks, i.e., guaranteed packet transport with bounded latency, low packet delay variation, and low packet loss.This document summarizes and evaluates various queuing technologies of TSN as reference information for Scaling Deterministic Networks Requirements[I-D.ietf-detnet-scaling-requirements] and Enhancing Deterministic Forwarding. |
| SRv6 Context Indicator SIDs for SR-Aware Services |
|
|
A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. |
| Intel Profile for CoRIM |
|
|
This document describes extensions to the CoRIM schema that support Intel specific Attester implementations. Multiple Evidence formats are compatible with base CoRIM, but extensions to evidence formats may be required to fully support the CoMID schema extensions defined in this profile. The concise evidence definition uses the CoMID schema such that extensions to CoMID are inherited by concise evidence. Reference Value Providers may use this profile to author mainifests containing Reference Values and Endorsements. RATS Verifiers recognize this profile by it's profile identifier and implement support for the extentions defined. |
|
|
| |
| The DRIP DET public Key Infrastructure |
|
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. |
| 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. |
| 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. |
| JSON semantic format (JSON-NTV) |
|
|
This document describes a set of simple rules for unambiguously and concisely encoding semantic data into JSON Data Interchange Format. These rules are based on an NTV (Named and Typed Values) data structure applicable to any simple or complex data. The JSON-NTV format is its JSON translation. |
| NTV tabular format (NTV-TAB) |
|
|
This document describes a set of simple rules for unambiguously and concisely encoding semantic tabular and multidimensional data (NTV- TAB format). These rules are based on the NTV structure and its JSON representation (JSON-NTV format). |
| Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC |
|
|
This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval. |
| URN Namespace for Metaverse Standards Forum Resources |
|
|
This document describes the Namespace IDentifier (NID) 'metaverse- standards-org' for Uniform Resource Names (URNs) used to identify resources published by Metaverse Standards Forum. The forum specifies and manages resources that utilize this URN identification model. Example resources include ressources, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, and other types of resources produced or managed by the Metaverse Standards Forum. |
| CoAP in Space |
|
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the scenario where an IP protocol stack is used for deep space communication. |
|
|
| |
| 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. |
| Applicability Statement for IETF Core Email Protocols |
|
| draft-ietf-emailcore-as-09.txt |
| Date: |
18/12/2023 |
| Authors: |
John Klensin, Kenneth Murchison, Ekow Sam |
| Working Group: |
Revision of core Email specifications (emailcore) |
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. |
| 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. |
| BGP Colored Prefix Routing (CPR) for SRv6 based Services |
|
| draft-ietf-idr-cpr-00.txt |
| Date: |
18/12/2023 |
| 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 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 SIDs under the corresponding SRv6 locators, which are advertised as Colored prefixes. This 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. In data plane, dedicated transport label or SID for the inter-domain path is not needed, thus the encapsulation efficiency could be optimized. The existing IPv6 Address Family could be used for the advertisement of IPv6 Colored prefixes, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks. |
| 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. |
| 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. |
| HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP) |
|
|
This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System (BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS). Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management. |
| Security Services for the Industrial Internet Identifier Data Access Protocol (IIIDAP) |
|
|
The Industrial Internet Identifier Data Access Protocol (IIIDAP) provides "RESTful" web services to retrieve identifier metadata from Second-Level Node (SLN). This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for IIIDAP. |
| JSON Responses for the Industrial Internet Identifier Data Access Protocol (IIIDAP) |
|
|
This document describes JSON data structures representing identifier information maintained by Second-Level Nodes (SLN). These data structures are used to form Industrial Internet Identifier Data Access Protocol (IIIDAP) query responses. |
| Finding the Authoritative Registration Data (IIIDAP) Service |
|
|
This document specifies a method to find which Industrial Internet Identifier Data Access Protocol (IIIDAP) server is authoritative to answer queries for a request of identifier data. |
| Industrial Internet Identifier Data Access Protocol (IIIDAP) Query Format |
|
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve identifier information from Second-Level Nodes (SLN) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Industrial Internet Identifier Data Access Protocol (IIIDAP). |
| Use cases with Requirements for Packet Optical Integration (POI) Under ACTN Framework |
|
|
This document provides general overarching guidelines for control and management of packet over optical converged networks and focuses on operators' use cases with requirements and network topologies. It provides a set of use cases and requirements which are needed to achieve full automation for control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on coherent pluggables. It is intended that other IETF drafts in this area reference this draft and abide by the use cases and requirements in this draft. The realization of these use cases is out of scope of this draft and shall be covered in other IETF drafts. |
|
|
| |
| 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 XXXX 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. |
| BGP SR Policy Extensions for Segment List Identifier |
|
|
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. This document defines extensions to BGP SR Policy to specify the identifier of segment list. |
| 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. |
|
|
| |
| 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. |
| Framework for CID Flow Indicator (CIDFI) |
|
| draft-wing-cidfi-04.txt |
| Date: |
14/12/2023 |
| Authors: |
Dan Wing, Tirumaleswar Reddy.K, Mohamed Boucadair |
| Working Group: |
Individual Submissions (none) |
|
Host-to-network signaling and network-to-host signaling can improve the user experience to adapt to network's constraints and share expected application needs, and thus to provide differentiated service to a flow and to packets within a flow. The differentiated service may be provided at the network (e.g., packet prioritization), the server (e.g., adaptive transmission), or both. This document describes how clients can communicate with their nearby network elements so they can learn network constraints. Optionally, with QUIC server support their incoming QUIC packets can be mapped to metadata about their contents so packet importance can influence both intentional and reactive management policies. The framework handles both directions of a flow. |
| MLS Virtual Clients |
|
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. |
| BGP Next-next Hop Nodes |
|
|
BGP speakers learn their next hop addresse for NLRI in [RFC4271] in the NEXT_HOP field and in [RFC4760] in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. [I-D.ietf-idr-entropy-label] defines the "Next Hop Dependent Capabilities Attribute" (NHC) which allows a BGP speaker to signal the forwarding capabilities associated with a given next hop. This document defines a new NHC capability, the Next-next Hop Nodes (NNHN) capability, which can be used to advertise the next-next hop nodes associated with a given next hop. |
| Updating the NTP Registries |
|
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries, and makes updates where necessary. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. |
| A Profile for Route Origin Authorizations (ROAs) |
|
|
This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. |
| Implementing Interfaces to Transport Services |
|
| draft-ietf-taps-impl-18.txt |
| Date: |
14/12/2023 |
| Authors: |
Anna Brunstrom, Tommy Pauly, Reese Enghardt, Philipp Tiesel, Michael Welzl |
| Working Group: |
Transport Services (taps) |
|
The Transport Services system enables applications to use transport protocols flexibly for network communication and defines a protocol- independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementing such a system. |
|
|
| |
| Network Programming extension: SRv6 uSID instruction |
|
| draft-filsfils-spring-net-pgm-extension-srv6-usid-16.txt |
| Date: |
13/12/2023 |
| Authors: |
Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Dan Voyer, Israel Meilik, Keyur Patel, Wim Henderickx, Prem Jonnalagadda, David Melman, Yisong Liu, Jim Guichard |
| Working Group: |
Individual Submissions (none) |
|
The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: * The SRv6 Control Plane is leveraged without any change * The SRH dataplane encapsulation is leveraged without any change * Any SID in the SID list can carry micro segments * Based on the Compressed SRv6 Segment List Encoding in SRH |
| 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. |
| SCHC Access Control |
|
|
The framework for SCHC defines an abstract view of the rules, formalized through a YANG Data Model. In its original description, rules are static and shared by two endpoints. This document defines defines augmentation to the existing Data Model in order to restrict the changes in the rule and, therefore, the impact of possible attacks. |
|
|
| |
| Adaptive Subscription to YANG Notification |
|
|
This document defines a YANG data model and associated mechanism that enable adaptive subscription to a publisher's event streams. The periodic update interval for the event streams can be set adaptively. Applying these elements allows servers to automatically adjust the rate and volume of telemetry traffic sent from a publisher to receivers. |
| Generating the Transport Key Containers Using the GOST Algorithms |
|
|
This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to generate the transport key containers for storing keys and certificates in conjunction with the Russian national standard GOST algorithms. This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here. |
| Merkle Tree Ladder Mode (MTL) 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. |
| An HTTP Status Code to Report Requester Impairment |
|
|
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when an operation or resource is denied due to requester impairment. |
|
|
| |
| BGP Extensions of SR Policy for Headend Behavior |
|
|
This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. |
| YANG Data Model for RPKI to Router Protocol |
|
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| Signaling In-Network Computing operations (SINC) deployment considerations |
|
|
This document is intended to discuss some deployment aspects of "Signaling In-Network Computing operations" (SINC). Based on some examples, this document analyzes how each device in the SINC chain undertakes its own functions. This document showcase the use of SINC mechanism. |
| Versioning in the Registration Data Access Protocol (RDAP) |
|
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. |
|
|
| |
| Weighted Multi-Path Procedures for EVPN Multi-Homing |
|
| draft-ietf-bess-evpn-unequal-lb-21.txt |
| Date: |
07/12/2023 |
| Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| Working Group: |
BGP Enabled ServiceS (bess) |
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. |
| Template-Driven HTTP CONNECT Proxying for TCP |
|
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| Fast HIP Host Mobility |
|
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. |
| AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3 and QUIC |
|
|
This documents proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. |
| 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. |
| 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. |
| Origin-Bound One-Time Codes |
|
|
This specification defines a mechanism for associating one-time codes with domains that can be included in the body of an SMS message or the headers of an email. |
| BGP Flow Specification Extensions for Traffic Statistics |
|
|
RFC8955 defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document extends RFC 8955 with New traffic Filtering Actions. statistic for bytes rate per second and statistic for packets rate per second are useful in specified Flow processing scenario. |
| Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
|
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
|
|
| |
| 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. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. 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. |
| Concise TA Stores (CoTS) |
|
|
Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. |
| Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP |
|
|
The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ECN in Section 13 of RFC 3819, by replacing it with a reference to the whole of this document. |
| Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim |
|
|
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. |
|
|
| |
| EVPN Multi-Homing Extensions for Split Horizon Filtering |
|
|
Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other tunnels, E.g., VXLAN tunnels. The existing specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document updates the EVPN Multihoming procedures in RFC8365 and RFC7432 so that an operator can decide the Split Horizon procedure for a given tunnel depending on their own requirements. |
| DNS Multiple QTYPEs |
|
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. |
| PEM file format for ECH |
|
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. |
| k-of-n Composite Signatures for Multi-Algorithm PKI |
|
|
With the need to evolve the cryptography used in today applications, devices, and networks, there are many scenarios where the use of a single-algorithm is not sufficient. For example, there might be the need for migrating between two existing algorithms because of a weakening of earlier generations (e.g., from classic or traditional to post-quantum or quantum-safe). Another example might involve the need to test, instead, the capabilities of devices via test drivers and/or non-standard algorithms. Another very common case is the need to combine certified cryptography (e.g., FIPS) with newer algorithms that are not yet certified or that are not planned for certification. This work extends the options provided by Explicit Composite, defined in [I-D.ounsworth-pq-composite-sigs], by providing a mechanism to manage backward and forward compatibility via k-of-n signature validation procedures. This document provides the definition of a new type of the kofn- CompositePublicKey and kofn-CompositeSignature which are aligned with the definitions of the respective structures for Explicit Composite [I-D.ounsworth-pq-composite-sigs]. |
| PCEP Extensions to support BFD parameters |
|
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. |
| 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. |
| Export of Flow Precision Availability Metrics Using IPFIX |
|
|
This document defines a set of IP Flow Information Export (IPFIX) Information Elements to export precision availability data associated with Flows, specifically Flows that are associated with stringent Service Level Objectives (SLOs) such as latency or packet delay variation. |
|
|
| |
| Framework for Cyberspace Resources Categorization |
|
| draft-jilongwang-opsawg-crc-06.txt |
| Date: |
03/12/2023 |
| Authors: |
Jilong Wang, Congcong Miao, Shuying Zhuang, Qianli Zhang, Chengyuan Zhang |
| Working Group: |
Individual Submissions (none) |
|
This memo presents the definition of cyberspace resource, and then discusses a classification framework for cyberspace resources. Cyberspace is widely applied in people's daily life and it is regarded as a new space, paralleled to the geographic space. There are various resources in cyberspace. However, they have not been systematically defined and classified. The objective of this draft is to present the deifinition of cyberspace resource and a standard classification framework, thus, supporting the unified resource storage and shares. |
| 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) definitions. 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). |
|
|
| |
| Delegated Credentials to Host Encrypted DNS Forwarders on CPEs |
|
|
An encrypted DNS server is authenticated by a certificate signed by a Certificate Authority (CA). However, for typical encrypted DNS server deployments on Customer Premise Equipment (CPEs), the signature cannot be obtained or requires excessive interactions with a Certificate Authority. This document explores the use of TLS delegated credentials for a DNS server deployed on a CPE. This approach is meant to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. |
| Confidential Virtual Machine Provisioning in Cloud Environment |
|
|
This document specifies the procedures of provisioning confidential virtual machine in the cloud environment. |
| Path Tracing in SRv6 networks |
|
| draft-filsfils-ippm-path-tracing-00.txt |
| Date: |
01/12/2023 |
| Authors: |
Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija |
| Working Group: |
Individual Submissions (none) |
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. |
| RATS Endorsements |
|
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats needed by a Relying Parties. This document explains the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements. |