| |
|
| |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-40.txt |
| | Date: |
10/11/2024 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | An IPv4 Flowlabel Option |
| |
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. |
| | Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) |
| |
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. |
| | Applicability of Reliable Server Pooling for Real-Time Distributed Computing |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. |
| | Secure SCTP |
| |
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. |
| | Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility |
| |
|
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). |
| | Reliable Server Pooling (RSerPool) Bakeoff Scoring |
| |
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. |
| | Considerations for Information Services and Operator Services Using SIP |
| |
|
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. |
| | Handle Resolution Option for ASAP |
| |
|
This document describes the Handle Resolution option for the ASAP protocol. |
| | Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling |
| |
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. |
| | Takeover Suggestion Flag for the ENRP Handle Update Message |
| |
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. |
| | A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD) |
| |
|
This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. |
| | The i;codepoint collation |
| |
|
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. |
| | A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) |
| |
| | draft-spinosa-urn-lex-24.txt |
| | Date: |
17/08/2024 |
| | Authors: |
PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a Uniform Resource Name (URN) Namespace Identifier for identifying, naming, assigning, and managing persistent resources in the legal domain. This specification is published to allow adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain. This specification is an independent submission to the RFC series. It is not a standard, and does not have the consensus of the IETF. |
| | Xon/Xoff State Control for Telnet Com Port Control Option |
| |
|
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. |
| | Load Sharing for the Stream Control Transmission Protocol (SCTP) |
| |
| | draft-tuexen-tsvwg-sctp-multipath-28.txt |
| | Date: |
05/09/2024 |
| | Authors: |
Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart |
| | Working Group: |
Individual Submissions (none) |
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. |
| | Clarification of Proper Use of "@" (at sign) in URI-style Components |
| |
|
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. |
| | Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA) |
| |
|
This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. |
| | SCTP Socket API Extensions for Concurrent Multipath Transfer |
| |
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. |
| | Sender Queue Info Option for the SCTP Socket API |
| |
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. |
| | Encoding the graphemes of the SignWriting Script with the x-ISWA-2010 |
| |
|
For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. |
| | The FNV Non-Cryptographic Hash Algorithm |
| |
| | draft-eastlake-fnv-30.txt |
| | Date: |
02/02/2025 |
| | Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| | Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that is widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. |
| | Route Flap Damping Deployment Status Survey |
| |
|
BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping. |
| | Unified User-Agent String |
| |
|
User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use. |
| | SNMPD to use cache and shared database based on MIB Classification |
| |
|
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. |
| | Analysis of Algorithms For Deriving Port Sets |
| |
|
This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. |
| | An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation |
| |
|
An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. |
| | Web Cache Communication Protocol V2,Revision 1 |
| |
|
This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. |
| | The application/stream+json Media Type |
| |
|
This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. |
| | Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems |
| |
|
This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. |
| | I-PAKE: Identity-Based Password Authenticated Key Exchange |
| |
|
Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. |
| | 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. |
| | Ruoska Encoding |
| |
|
This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. |
| | ICANN Registry Interfaces |
| |
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| | QoS-level aware Transmission Protocol (QTP) for virtual networks |
| |
| | draft-lan-nvo3-qtp-20.txt |
| | Date: |
05/10/2024 |
| | Authors: |
Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. |
| | Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol |
| |
|
The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. |
| | Metadata Query Protocol |
| |
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. |
| | Ideas for a Next Generation of the Reliable Server Pooling Framework |
| |
|
This document collects some idea for a next generation of the Reliable Server Pooling framework. |
| | Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol |
| |
|
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. |
| | Generic Fault-Avoidance Routing Protocol for Data Center Networks |
| |
| | draft-sl-rtgwg-far-dcn-23.txt |
| | Date: |
06/01/2025 |
| | 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. |
| | SAML Profile for the Metadata Query Protocol |
| |
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.23. |
| | Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation |
| |
|
Resource sharing in a network means two or more Label Switched Paths (LSPs) use common pieces of resource along their paths. This can help save network resources and is useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is responsible for path computation with such requirement. Existing extensions to the Path Computation Element Protocol (PCEP) allow one path computation request for an LSP to be associated with other (existing) LSPs through the use of the PCEP Association Object. This document extends PCEP in order to support resource-sharing-based path computation as another use of the Association Object to enable better efficiency in the computation and in the resultant paths and network resource usage. |
| | 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. |
| | Just because it's an Internet-Draft doesn't mean anything... at all... |
| |
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| | Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP) |
| |
|
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. |
| | TCP SYN Extended Option Space Using an Out-of-Band Segment |
| |
|
This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. |
| | Service Function Path Establishment |
| |
|
Service Function Chain architecture leads to more adaptive network nodes. It allows splitting the network function into fine-grained build blocks --- service function, and combining the network functions into service function chain to formulate complicated services. Further, the service function chain should be instantiated by selecting the optimal instance from the candidates for each service function in it. This document discusses the required components during the instantiation of service function chain in the network. |
| | Egress Peer Engineering using BGP-LU |
| |
| | draft-gredler-idr-bgplu-epe-16.txt |
| | Date: |
14/10/2024 |
| | Authors: |
Hannes Gredler, Kaliraj Vairavakkalai, Chandrasekar R, Balaji Rajagopalan, Ebben Aries, Luyuan Fang |
| | Working Group: |
Individual Submissions (none) |
|
The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links. |
| | Node Potential Oriented Multi-NextHop Routing Protocol |
| |
|
The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP) bases on the idea of "hop-by-hop routing forwarding, multi-backup next hop" and combines with the phenomena that water flows from higher place to lower. NP-MNRP defines a metric named as node potential, which is based on hop count and the actual link bandwidth, and calculates multiple next-hops through the potential difference between the nodes. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| | Mathematical Mesh 3.0 Part I: Architecture Guide |
| |
|
The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html. |
| | Mathematical Mesh: Reference Implementation |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html. |
| | Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
| |
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| | Multiple IPv4 - IPv6 address mapping translator (M46T) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| | Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E) |
| |
|
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. |
| | Multi-Stage Transparent Server Load Balancing |
| |
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets |
| |
|
RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification of the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets for which the verification tag can not be checked. |
| | Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
| |
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| | 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. |
| | PCEP Extension for Distribution of Link-State and TE Information for Optical Networks |
| |
| | draft-lee-pce-pcep-ls-optical-15.txt |
| | Date: |
13/01/2025 |
| | Authors: |
Yang Zhao, Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin Yoon |
| | Working Group: |
Individual Submissions (none) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. |
| | Mathematical Mesh: Platform Configuration |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html. |
| | 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. |
| | 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 taxonomy format |
| |
|
This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. |
| | Encapsulating IPsec ESP in UDP for Load-balancing |
| |
| | draft-xu-ipsecme-esp-in-udp-lb-13.txt |
| | Date: |
07/10/2024 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Boris Pismenny, Dacheng Zhang, Liang Xia, Mahendra Puttaswamy |
| | Working Group: |
Individual Submissions (none) |
|
IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic. |
| | 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. |
| | 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. |
| | Mobility Capability Negotiation |
| |
| | draft-yan-dmm-man-14.txt |
| | Date: |
19/09/2024 |
| | Authors: |
Zhiwei Yan, Tianji Jiang, Jianfeng Guan, Tao Huang, Jong-Hyouk Lee |
| | Working Group: |
Individual Submissions (none) |
|
Mobile peers exchange signals with networks, for both wireline and wireless domains, to negotiate capabilities for mobile registration, connection management, session establishment, service provisioning, etc. Generally, mobility capabilities include the supported and provisioned resources along with associated protocols for certain mobility management scenarios. While devices in the mobile wireline (IP) domain would mostly focus on the IP-related negotiation, devices in the wireless domain, e.g., the 5G system (5GS), embrace both mobile IP-related resources as well as wireless-specific capabilities. Regarding both the mobile-IP and wireless domains, we have generalized two protocol categories for mobility capability negotiation & management, i.e., the host-initiated category that involves the direct & active engagement of mobile end devices vs. the network-based category over which mobile endpoints play almost no role in the process. The classification and then the application of the two categories help us analyze the mobility capability negotiation for both the mobile IPv6 and the 3GPP 5G system. The comparison of the capability negotiation under both the Home-Routed (HR) and the Local BreakOut (LBO) roaming cases in 5GS further reflects the feasibility of the protocol dichotomy. |
| | BGP Logical Link Discovery Protocol (LLDP) Peer Discovery |
| |
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. |
| | Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing |
| |
| | draft-perkins-manet-aodvv2-05.txt |
| | Date: |
22/11/2024 |
| | Authors: |
Charles Perkins, John Dowdell, Lotte Steenbrink, Victoria Pritchard |
| | Working Group: |
Individual Submissions (none) |
|
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. |
| | NEAT Sockets API |
| |
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. |
| | IPv6 is Classless |
| |
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| | BGP Signaled MPLS Namespaces |
| |
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| | IPv6-only Terminology Definition |
| |
|
This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. |
| | Reassignment of System Ports to the IESG |
| |
|
In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate. |
| | A YANG Data Model for Client-layer Tunnel |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. |
| | CoAP: Non-traditional response forms |
| |
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated. |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 12 of this protocol. |
| | 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. The intended status for this document is Informational RFC. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | IPv4+ The Extended Protocol Based On IPv4 |
| |
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. |
| | ICANN Registrar Interfaces |
| |
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| | DNS Web Service Discovery |
| |
|
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html. |
| | Flexible Session Protocol |
| |
|
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management |
| | Access Extensions for ANCP |
| |
|
The purpose of this document is to specify extensions to ANCP (Access Node Control Protocol) (RFC6320) to support PON as described in RFC6934 and some other DSL Technologies including G.fast. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. |
| | Discovery of OSCORE Groups with the CoRE Resource Directory |
| |
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | Flowspec Indirection-id Redirect for SRv6 |
| |
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| | CoRE Resource Directory Extensions |
| |
|
A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX |
| |
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. |
| | Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. |
| |
|
This document describes the underlying naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. For convenience, UDFs are typically presented to the user in the form of a Base32 encoded string. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. |
| | Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE) |
| |
|
This document describes the Data At Rest Encryption (DARE) Envelope and Sequence syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Sequence syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Sequences may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html. |
| | Proxy MAC-IP Advertisement in EVPNs |
| |
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | 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. |
| | Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms |
| |
|
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the Mesh. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- cryptography.html. |
| | Mathematical Mesh 3.0 Part V: Protocol Reference |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. |
| | Mathematical Mesh 3.0 Part IV: Schema Reference |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. |
| | A Framework for Constructing Service Function Chaining Systems Based on Segment Routing |
| |
|
Segment Routing (SR) introduces a versatile methodology for defining end-to-end network paths by encoding sequences of topological sub- paths, known as "segments". This architecture can be deployed over both MPLS and IPv6 data planes, offering a flexible routing solution. Service Function Chaining (SFC) supports the establishment of composite services through an ordered sequence of Service Functions (SFs) that are applied to packets or frames based on initial classification. SFC's implementation can utilize various underlying technologies, including the Network Service Header (NSH) and SR, to facilitate the creation and management of service chains. This document presents a comprehensive control framework for developing SFC architectures using Segment Routing. It explores control plane solutions for the distribution of service function instance routes and service function paths, as well as techniques for directing packets into specific service function chains. The discussion encompasses both theoretical foundations and practical considerations for integrating SR into SFC deployments. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the "charset" that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines "Modern Network Unicode" (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency |
| |
|
This informational document explains the specification of the queue protection algorithm used in DOCSIS technology since version 3.1. A shared low latency queue relies on the non-queue-building behaviour of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the queue protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low latency queue by ejecting selected packets (or all packets) of these flows. The document is designed for four types of audience: a) congestion control designers who need to understand how to keep on the 'good' side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm. |
| | Protocol Assisted Protocol (PASP) |
| |
|
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP( BGP Monitoring Protocol), for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PASP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues. |
| | 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. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| | Software Version Capability for BGP |
| |
|
In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. |
| | Maintaining CCNx or NDN flow balance with highly variable data object sizes |
| |
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| | 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. |
| | 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. |
| | Stateless OpenPGP Command Line Interface |
| |
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. |
| | Performance Measurement for Geneve |
| |
|
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
| | A YANG Data Model for Client Signal Performance Monitoring |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| | Destination-IP-Origin-AS Filter for BGP Flow Specification |
| |
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. |
| | IETF Network Slice Topology YANG Data Model |
| |
|
An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. |
| | Operational Considerations for BRSKI Registrar |
| |
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. |
| | Operational Considerations for Voucher infrastructure for BRSKI MASA |
| |
|
This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. |
| | Resource Allocation Model for Hybrid Switching Networks |
| |
|
The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. |
| | Approaches on Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | An Algorithm for Computing Dynamic Flooding Topologies |
| |
|
Link-state routing protocols suffer from excessive flooding in dense network topologies. RFC 9667, "Dynamic Flooding on Dense Graphs", alleviates the problem by decoupling the flooding topology from the physical topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the physical topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used as a flooding topology in dynamic flooding. This document discloses the algorithm that we have developed in order to make it easier for other developers to implement similar algorithms. We do not claim that our algorithm is optimal, rather it is a pragmatic effort and we expect that further research and refinement can improve the results. We are not proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work, however we have no objections if the working group chooses to do so. |
| | CoAP over GATT (Bluetooth Low Energy Generic Attributes) |
| |
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. |
| | Using Flex-Algo for Segment Routing (SR) based Network Resource Partition (NRP) |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique Flexible Algorithm (Flex-Algo), which can provide constraint-path computation based on the customized topological constraints. This document specifies a mechanism to build Segment Routing (SR) based NRPs by combining SR Flex-Algo and IGP L2 bundles with minor extensions. |
| | Crowd Sourced Remote ID |
| |
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| | UAS Operator Privacy for RemoteID Messages |
| |
|
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. |
| | Secure UAS Network RID and C2 Transport |
| |
|
This document defines a transport mechanism between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. Either the Broadcast Remote ID (B-RID) messages, or alternatively, appropriate MAVLink Messages can be sent directly over UDP or via a more functional protocol using CoAP/CBOR for the Net-RID messaging. This is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure messaging Command-and-Control (C2) for is also described. |
| | Notable CBOR Tags |
| |
|
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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
| |
|
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. |
| | 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. |
| | BGP Shortest Path Routing Extension Implementation Report |
| |
|
This document is an implementation report for the BGP Link-State Shortest Path First (SPF) Routing. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab. |
| | Trusted Path Routing |
| |
|
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-10.txt |
| | Date: |
23/11/2024 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection |
| |
|
This document defines optional TLVs which are carried in Simple Two- way Active Measurement Protocol (STAMP) test packets to enhance the STAMP based functions. Such extensions to STAMP enable performance measurement and collection at every node and link along a STAMP test packet's delivery path. It enables Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
| |
|
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS. |
| | Cacheable OSCORE |
| |
|
Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. |
| | Compact UUIDs for Constrained Grammars |
| |
|
The Universally Unique Identifier is a suitable standard for, as the name suggests, uniquely identifying entities in a symbol space large enough that the identifiers do not collide. Many formal grammars, however, are too restrictive to permit the use of UUIDs in their canonical representation (described in RFC 4122 and elsewhere), despite it being useful to do so. This document specifies an alternative compact representation for UUIDs that preserves some properties of the canonical form, with three encoding varietals, to fit these more restrictive contexts. |
| | Mathematical Mesh 3.0 Part XI: Mesh Presence Service |
| |
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Parent-side authoritative DNS records for enhanced delegation |
| |
|
DNS RR types with numbers in the range 0xFA00-0xFDFF are now included in special treatment like DS RR type specified in [RFC4035]. Authoritative servers, DNSSEC signers, and recursive resolvers need to extend the conditions for DS special handling to also include this range. This means: being authoritative on the parent side of a delegation; being signed by the parent; being provided along with delegations by the parent. DNSSEC validators also need to implement downgrade protection described in Section 5.3. |
| | The VERBATIM Digest Algorithm for DS records |
| |
|
The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. |
| | Federated TLS Authentication |
| |
|
This document describes the Federated TLS Authentication (FedTLS) protocol, enabling secure machine-to-machine communication within a federation. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedTLS ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. |
| | MSYNC |
| |
| | draft-bichot-msync-17.txt |
| | Date: |
02/12/2024 |
| | 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. |
| | Revised Cookie Processing in the IKEv2 Protocol |
| |
|
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | A taxonomy of eavesdropping attacks |
| |
|
The terms on-path attacker and MITM Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. Increasingly people have become uncomfortable with the gendered term "Man" in the middle and have sought alternatives. This document offers an update on terminology for network attacks, retaining some acronyms terms while redefining the expansion, and clarifying the different kinds of attacks. Consistent terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-10.txt |
| | Date: |
03/02/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. This protocol extension has been developed outside the IETF as an alternative to the IETF’s standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale deployment to determine the potential benefits of this approach. |
| | Signaling Composite Candidate Path of SR Policy using BGP-LS |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. |
| | PCEP Extensions for sid verification for SR-MPLS |
| |
|
This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. |
| | Layer-3 Accessible EVPN Services |
| |
|
This draft describes layer-3 accessible EVPN service interfaces, and proposes a new solution which can span layer-3 network. This solution allows each PE in EVPN network to maintain only one MAC-VRF. |
| | Advertising SRv6 SIDs for Layer 2 Bundle Member Links in IGP |
| |
|
There are deployments where the Layer-3 interface on which IGP operates is a Layer-2 interface bundle. Existing IGP advertisements only support advertising link attributes of the Layer-3 interface. If entities external to IGP wish to control traffic flows on the individual physical links that comprise the Layer-2 interface bundle, link attribute information about the bundle members is advertised by IGP extensions for Layer-2 (L2) bundle. When Segment Routing over IPv6 (SRv6) is used with Layer-2 interface bundle to control traffic flows on the individual member links, the SRv6 SIDs which represent the Layer 2 member links of the L2 bundle needs to be advertised in IGP. This document proposes the IGP extensions to advertise the SRv6 SIDs of the Layer 2 (L2) bundle member links. |
| | Carrying NRP related Information in MPLS Packets |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Multiple NRPs can be created by network operator to meet the diverse requirements of enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used as the NRP Selector to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the NRP Selector ID and related information in MPLS packets. The procedure for processing the NRP Selector ID and related information is also specified. |
| | Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation |
| |
|
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. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. The present version of this document is mostly a proof of concept, but was deemed useful to obtain initial feedback on the approach taken. |
| | Security Technical Specification for Smart Devices of IoT |
| |
|
With the development of IoT, the security of smart devices has become an important issue for us to discuss. This draft proposes a security framework and detailed requirements in terms of hardware, system, data, network, and management to ensure the security of IoT smart devices. Specifically, hardware security includes the security of hardware interfaces and components. System security encompasses firmware security, security audits, and more. Data security involves data verification and protection of sensitive data.Network security entails stream protection, session security, and more. |
| | Technical Requirements for Secure Access and Management of IoT Smart Terminals |
| |
|
It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. |
| | Open Service Access Protocol for IoT Smart Devices |
| |
|
With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Mathematical Mesh 3.0 Part VII: Mesh Callsign Service |
| |
|
The Mesh Callsign Registry is a name registry that provides a mapping from human-friendly callsigns to root of trusts and a service assigned by the callsign holder to service the account bound to that callsign. An append only sequence authenticated by means of a Merkle Tree and periodic third party notarizations provides ground truth for the integrity of the registry and for all the assertions enrolled in the sequence. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Data Transmission Security of Identity Resolution in Industrial Internet |
| |
|
This draft presents a comprehensive overview of the data transmission security within the identity resolution system for the Industrial Internet. Identity resolution systems play a vital role in the Industrial Internet, facilitating secure sharing and intelligent correlation of heterogeneous information across various organizations. This draft focuses on the security services that identity resolution systems should provide during the resolution process. |
| | Retrieving information about Object Identifiers in a consistent way that is both human-readable and machine-readable. |
| |
|
This document defines a method for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) through the HTTP or WHOIS protocol, in a way that is both human-readable and machine-readable. Besides a text output format, OID-IP also supports sending information in JSON and XML. |
| | PCEP Procedures and Extension for VLAN-based Traffic Forwarding |
| |
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key procedures of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. |
| | SRv6-based BGP Service Capability |
| |
|
[RFC9252] specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis. This document provides analysis on the problems that may be encountered if the SRv6-based service routes are received by the MPLS-only PEs. Some currently used SRv6-based service routes advertisement controlling methods by configuration or network planning are also described. And this document proposes an automatic advertisement controlling method for SRv6-based service routes by defining a new Capability Code for SRv6-based BGP service capability. |
| | SRv6 inter-domain mapping SIDs |
| |
|
This document describes three new SRv6 end-point behaviors, called END.REPLACE, END.REPLACEB6 and END.DB6. These behaviors are used in distributed inter-domain solutions and are normally executed on border routers. They also can be used to provide multiple intent- based paths across these domains. |
| | 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 use of Access Control Lists, 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, |
| | EVPN multi-homing support for L3 services |
| |
|
This document introduces the utilization of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to enhance network availability and load balancing for various L3 services in EVPN. |
| | Encoding Network Slice Identification for SRv6 |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | 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. |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | MTU propagation over EVPN Overlays |
| |
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. |
| | Mathematical Mesh 3.0 Part VI: Reliable User Datagram |
| |
|
A presentation layer suitable for use in conjunction with HTTP and UDP transports is described. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | BGP-LS extensions for BIER-TE |
| |
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. |
| | Defreezing Optimization post EVPN Mac Dampening |
| |
|
MAC move handling in EVPN deployments is discussed in detail in [RFC7432]. There are few optimizations which can be done in existing way of handling the mac duplication. This document describes few of the potential techniques to do so. This document is of informational type based on comments in the ietf meeting. |
| | All PEs as DF |
| |
|
The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. |
| | Extending ICMPv6 for SRv6-related Information Validation |
| |
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. |
| | Segment Routing in Two Dimensional IP Routing |
| |
|
Segment Routing (SR) allows a headend node to steer traffic into a Segment Routing Policy (SR Policy), which represents the routing path by matching the destination address and the corresponding Binding Segment Identifier (BSID). However, determining the target SR Policy only based on destination aspect is incapable for demands for higher dimensional routing. Two Dimensional IP (TwoD-IP) routing is an Internet routing architecture that makes forwarding decisions based on source and destination addresses. TwoD-IP routing can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to the higher dimensional routing. In this document, we extend SR to support TwoD-IP routing, illustrate some typical scenarios of SR with TwoD-IP routing to express the advantage of extending SR to support TwoD-IP routing, and describe the mechanism of how TwoD IP routing protocol cooperates with SR. |
| | Juniper's Secure Vector Routing (SVR) |
| |
| | draft-menon-svr-07.txt |
| | Date: |
04/11/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 headers. 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. |
| | Procedure for Standards Track Documents to Refer Normatively to External Documents |
| |
|
This document specifies a procedure for referencing external standards and specifications from IETF-produced documents on the Standards Track. In doing so, it updates BCP 9 (RFC 2026). |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | A UDP-based GMA (Generic Multi-Access) Protocol |
| |
|
A device can simultaneously connect to multiple access networks, e.g., Wi-Fi, LTE, 5G, DSL, and SATCOM (Satellite Communications). It is desirable to seamlessly combine multiple connections over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built-in multi- path capabilities. This document presents a new convergence protocol for managing data traffic across multiple network paths. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations to experiment with the protocol. |
| | Updated Rules for PCE Communication Protocol (PCEP) Object Ordering |
| |
|
The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these messages are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. |
| | 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. |
| | Artificial Intelligence Framework for Network Management |
| |
|
The adoption of artificial intelligence (AI) in network management (NM) solutions is the way to resolve many of the complex management problems arising from the adoption of NFV and SDN technologies. The AINEMA framework, as discussed in this document, includes the functions, capabilities, and components that MUST be provided by AI modules and models to be successfully applied to NM. This is enhanced by the consideration of seamless integration of different services, including the ability of having multiple AI models working in parallel, as well as the ability of complex reasoning and event processing. In addition, disparate sources of information are put together without increasing complexity, through the definition of a control and management service bus. It allows, for instance, to involve external events in NM operations. Using all available sources of information --- namely, intelligence sources --- allows NM solutions to apply proper intelligence processes that provide explainable results instead of simple AI-based guesses. Such processes are highly based in reasoning and formal and target-based intelligence analysis and decision --- providing evidence-based conclusions and proofs for the decisions --- in the form of AI method outputs with explanations. This will allow computer and network system infrastructures --- and user demands --- to grow in complexity while keeping dependability. Finally, AINEMA has the ability of distributing AI questions among several AI services, potentially from several vendors, in either a recursive or iterative fashion. |
| | 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. |
| | Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option |
| |
| | draft-tllq-tsr-05.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Ted Lemon, Liang Qin |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD Advertising Proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. |
| | BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches |
| |
|
MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. |
| | Multicast VPN Upstream Designated Forwarder Selection |
| |
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. |
| | Traffic Mapping YANG model for Traffic Engineering (TE) |
| |
|
This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model provides the operator a seamless control and management of which traffic to send on the underlying TE resources. |
| | IETF Network Slice Deployment Status and Considerations |
| |
|
Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided. |
| | Flow Measurement in IPv6 Network |
| |
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. |
| | Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |
| |
|
This document updates requirements on implementations of various Salted Challenge Response Authentication Mechanism (SCRAM) Simple Authentication and Security Layer (SASL) mechanisms based on more modern security practices. |
| | 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. |
| | EVPN Fast Reroute |
| |
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| | BGP SR Policy Extensions for template |
| |
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. |
| | 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. |
| | 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. |
| | Unicast Use of the Formerly Special-Cased 127/8 |
| |
|
This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. |
| | Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements |
| |
|
PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-08.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-07.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | Open Ethics Transparency Protocol |
| |
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. |
| | Link-Local Next Hop Capability for BGP |
| |
|
BGP [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. Because of this, as per [RFC4291] - BGP does not recognize IPv6 link-local addresses, as a valid next hop for the forwarding purposes. However, in many current deplyments, BGP peering is often deployed on point-to-point links in networks where multihop reachability of any kind is not assumed or desired (all next hops are assumed to be the speaker reachable through a directly connected point-to-point link). This is common, for instance, in data center fabrics [RFC7938]. In these situations, a global IPv6 address is not required for the advertisement of reachability information; in fact, providing global IPv6 addresses in these kinds of networks can be detrimental to Zero Touch Provisioning (ZTP). This draft standardizes the operation of BGP over a point-to-point link using link-local IPv6 addressing only. |
| | IPlir network layer security protocol |
| |
| | draft-iplir-protocol-06.txt |
| | Date: |
13/09/2024 |
| | Authors: |
Martishina Alexandra, Urivskiy Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. |
| | DHCPv6 Extension Practices and Considerations |
| |
|
IP addresses assume an increasing number of attributes as communication identifiers to meet different requirements. Privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol as required. This document provides current extension practices and typical DHCPv6 server software in terms of extensions, defines a general model of DHCPv6, discusses some extension points, and presents extension cases. |
| | Deadline Based Deterministic Forwarding |
| |
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. |
| | Impact of DLTs on Provider Networks |
| |
|
This document discusses the impact of distributed ledger technologies being realized over IP-based provider networks. The focus here lies on the impact that the DLT communication patterns have on efficiency of resource usage in the underlying networks. We provide initial insights into experimental results to quantify this impact in terms of inefficient and wasted communication, aligned along challenges that the DLT realization over IP networks faces. This document intends to outline this impact but also opportunities for network innovations to improve on the identified impact as well as the overall service quality. While this document does not promote specific solutions that capture those opportunities, it invites the wider community working on DLT and network solutions alike to contribute to the insights in this document to aid future research and development into possible solution concepts and technologies. The findings presented here have first been reported within the similarly titled whitepaper released by the Industry IoT Consortium (IIC) [IIC_whitepaper]. |
| | PCEP Extension for Bounded Latency |
| |
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry the bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Everything over CoAP |
| |
|
The Constrained Application Protocol (CoAP) has become the base of applications both inside of the constrained devices space it originally aimed for and outside. This document gives an overview of applications that are, can, may, and would better not be implemented on top of CoAP. |
| | 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. |
| | IETF Network Slice Service Mapping YANG Model |
| |
|
This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/ VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models. |
| | Advertisement of Dedicated Metric for Flexible Algorithm in IGP |
| |
|
This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks |
| |
|
Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. |
| | Considerations of network/system for AI services |
| |
| | draft-hong-nmrg-ai-deploy-07.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Ho-Sun Yoon, Pedro Martinez-Julia |
| | Working Group: |
Individual Submissions (none) |
|
As the development of AI technology matured and AI technology began to be applied in various fields, AI technology is changed from running only on very high-performance servers with small hardware, including microcontrollers, low-performance CPUs and AI chipsets. In this document, we consider how to configure the network and the system in terms of AI inference service to provide AI service in a distributed method. Also, we describe the points to be considered in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying network-based AI services, such as self-driving vehicles and network digital twins, are described. |
| | Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries |
| |
|
A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses including addressing and packet labeling information that is dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). |
| | BGP Extensions for the Mobile User Plane (MUP) SAFI |
| |
| | draft-mpmz-bess-mup-safi-05.txt |
| | Date: |
13/02/2025 |
| | Authors: |
Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. |
| | 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. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | TCP RST Diagnostic Payload |
| |
|
This document specifies a diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. |
| | The IP Geolocation HTTP Client Hint |
| |
|
Techniques that improve user privacy by hiding original client IP addresses, such as VPNs and proxies, have faced challenges with server that rely on IP addresses to determine client location. Maintaining a geographically relevant user experience requires large pools of IP addresses, which can be costly. Additionally, users often receive inaccurate geolocation results because servers rely on geo-IP feeds that can be outdated. To address these challenges, we can allow clients to actively send their network geolocation directly to the origin server via an HTTP Client Hint. This approach will not only enhance geolocation accuracy and reduce IP costs, but it also gives clients more transparency regarding their perceived geolocation. |
| | LISP for Satellite Networks |
| |
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. |
| | ACME-Based Provisioning of IoT Devices |
| |
|
This document extends the Automatic Certificate Management Environment (ACME) to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | BGP Blockchain |
| |
|
A variety of mechanisms have been developed and deployed over the years to secure BGP including the more recent RPKI/ROA mechanisms. Is it also possible to use a distributed ledger such as Blockchain to secure BGP? BGP provides decentralized connectivity across the Internet. Blockchain provides decentralized secure transactions in a append-only, tamper-resistant ledger. This document reviews possible opportunities of using Blockchain to secure BGP policies within a domain and across the global Internet. We propose that BGP data could be placed in a blockchain and smart contracts can control how the data is managed. This could create a single source of truth, something for which blockchains are particularly well suited. |
| | Dangerous Labels in DNS and E-mail |
| |
|
This document establishes registries that list known security- sensitive labels in the DNS and in e-mail contexts. It provides references and brief explanations about the risks associated with each known label. The registries established here offer guidance to the security-minded system administrator, who may not want to permit registration of these labels by untrusted users. |
| | Multicast Extension for QUIC |
| |
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. |
| | Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) |
| |
|
As operators migrate from an IPv4 core to an IPv6 core for global table routing over the internet, the need arises to be able provide routing connectivity for customers IPv4 only networks. This document provides a solution called 4Provider Edge, "4PE" that connects IPv4 islands over an IPv6-Only network. |
| | EVPN Mpls Ping Extension |
| |
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. |
| | Path Tracing in SR-MPLS networks |
| |
|
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 interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. |
| | 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. |
| | Extensible In-band Processing (EIP) Architecture and Framework |
| |
| | draft-eip-arch-05.txt |
| | Date: |
04/01/2025 |
| | 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. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | Asynchronous Deterministic Networking Framework for Large-Scale Networks |
| |
|
This document describes various solutions of Asynchronous Deterministic Networking (ADN) for large-scale networks. The solutions in this document do not need strict time-synchronization of network nodes, while guaranteeing end-to-end latency or jitter. The functional architecture and requirements for such solutions are specified. |
| | Secure IP Binding Synchronization via BGP EVPN |
| |
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. |
| | NRP ID in SRv6 segment |
| |
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. |
| | Generalized IPv6 Tunnel (GIP6) |
| |
|
This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. |
| | IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
| |
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| | IGP Extensions for Advertising Node Index |
| |
| | draft-chen-lsr-adv-ni-05.txt |
| | Date: |
24/09/2024 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. |
| | IGP Extensions for Advertising Link Numbers |
| |
| | draft-chen-lsr-adv-lkno-05.txt |
| | Date: |
24/09/2024 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the link numbers assigned to the links originating at a node. |
| | Stateless Best Effort Multicast Using MRH |
| |
| | draft-chen-pim-be-mrh-05.txt |
| | Date: |
24/09/2024 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes stateless best effort Multicast along the shortest paths to the egress nodes of a P2MP Path/Tree. The multicast data packet is encapsulated in an IPv6 Multicast Routing Header (MRH). The MRH contains the egress nodes represented by the indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along the shortest path. There is no state stored in the core of the network. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| | draft-fossati-tls-attestation-08.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Hannes Tschofenig, Yaron Sheffer, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, Arto Niemi, Thomas Fossati |
| | Working Group: |
Individual Submissions (none) |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation Information in the DNS. |
| | Multi-Topology in PIM |
| |
| | draft-xz-pim-flex-algo-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Individual Submissions (none) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | Problem statement for Inter-domain Intent-aware Routing using Color |
| |
|
This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions. |
| | A Larger Internet Key Exchange version 2 (IKEv2) Payload |
| |
|
The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document defines an extension to IKEv2 that allows larger payloads. |
| | Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) |
| |
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. |
| | 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. |
| | 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. |
| | The R5N Distributed Hash Table |
| |
| | draft-schanzen-r5n-06.txt |
| | Date: |
02/09/2024 |
| | Authors: |
Martin Schanzenbach, Christian Grothoff, Bernd Fix |
| | Working Group: |
Individual Submissions (none) |
|
This document contains the R^5N DHT technical specification. R^5N is a secure distributed hash table (DHT) routing algorithm and data structure for decentralized applications. It features an open peer- to-peer overlay routing mechanism which supports ad-hoc permissionless participation and support for topologies in restricted-route environments. Optionally, the paths data takes through the overlay can be recorded, allowing decentralized applications to use the DHT to discover routes. This document defines the normative wire format of protocol messages, routing algorithms, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to guide implementation of R^5N and to ensure interoperability among implementations including the pre-existing GNUnet implementation. |
| | UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
| |
|
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality needed within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. It obsoletes RFC 6951. |
| | SCION Control Plane PKI |
| |
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture where the Control Plane PKI handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's Control Plane to authenticate and verify path information, and builds the basis for SCION's trust model based on Isolation Domains. This document describes the trust model behind the SCION's Control Plane PKI, including specifications of the different types of certificates and the Trust Root Configuration. It also specifies how to deploy the Control Plane PKI infrastructure. |
| | 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. |
| | SAV-based Anti-DDoS Architecture |
| |
|
Existing Source Address Validation (SAV) schemes can not effectively defend against IP Spoofing DDoS under incremental deployment. This document proposes SAV-based anti-DDoS architecture (SAV-D), a distributed defense architecture to enhance SAV's defense. The main idea of SAV-D is to collect and aggregate more threat data from existing SAV devices and then distribute crucial knowledge to widespread devices, thus significantly expanding defense across the entire network. |
| | A Blockchain Trusted Protocol for Intelligent Communication Network |
| |
|
This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. |
| | Additional addresses for QUIC |
| |
|
This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. |
| | 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. |
| | The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. |
| | Service Affinity Solution for TCP based Application |
| |
|
This draft proposes a service affinity solution between client and server based on the newly defined TCP Options. This solution can avoid the waste of resources caused by saving a large amount of customer status data in the network equipment, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing-aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources. |
| | Mappings Between XML2RFC v3 and AsciiDoc |
| |
|
This document specifies a mapping between XML2RFC v3 and AsciiDoc. The goal of this mapping and its associated tooling is to make writing an Internet-Draft as simple as possible, by converting any AsciiDoc formatted document into a valid Internet-Draft, ready to be submitted to the IETF. This is still work in progress and for the time being this mapping only ensures that any valid XML2RFC element can be generated from AsciiDoc. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-10.txt |
| | Date: |
07/11/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. |
| | 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 RFC 6790, "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 "MPLS Network Action (MNA) Sub-Stack Solution". |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610 and RFC 9165. The latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0". It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. It is intended to serve as a basis for prototypical implementations of CDDL 2.0. This document is intended to evolve over time; it might spawn specific documents and then retire or eventually be published as a roadmap document. |
| | LSP Ping/Traceroute for Enabled In-situ OAM Capabilities |
| |
|
This document describes the MPLS Node IOAM Information Query functionality, which uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. |
| | Encapsulation of BFD for SRv6 Policy |
| |
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. |
| | An EAT-based Key Attestation Token |
| |
| | draft-bft-rats-kat-05.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Mathias Brossard, Thomas Fossati, Hannes Tschofenig, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. |
| | MoQ relays for Support of High-Throughput Low-Latency Traffic in 5G |
| |
|
This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MoQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MoQ equivalent to what is possible for RTP. |
| | Mathematical Mesh 3.0 Part X: Everything |
| |
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Stateless Best Effort Multicast Simulations |
| |
| | draft-chen-pim-be-mrh-simu-04.txt |
| | Date: |
24/09/2024 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes simulations of stateless best effort Multicasts and lists a set of simulation results for different large network sizes and different tree sizes. |
| | Mathematical Mesh 3.0 Part IX: Mesh Notarized Signatures |
| |
|
Creation and verification of Mesh Notarized Signatures is described . A notarized signature is a signature whose time of creation is attested by one or more parties in addition to the signer. In the case of Mesh Notarized Signatures, the attesting parties is the set of all parties participating in a Notarization Mesh. This ideally includes the relying parties. Each participant in a Notarization Mesh maintains their own notary log in the form of a DARE sequence authenticated by a Merkle tree. Participants periodically cross notarize their personal notary log with those maintained by other parties. A Mesh Notarized Signature is bound in time as having being created after time T1 by including one or more sequence apex values as signed attributes. A Mesh Notarized Signature is bound in time as having being created before time T2 by enrolling it in the signer's personal notarization log and engaging in cross-notarization with a sufficient number of Notarization Mesh participants to establish the desired proof. Defection is controlled through an accountability model. If a trusted notary produces multiple inconsistent signed cross Notarization tokens, this provides non-repudiable evidence of a default. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Protocol Extension Requirements of Generalized IPv6 Tunnel |
| |
|
IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Slicing, Alternate Marking, IOAM, DetNet, APN. However network devices have different capabilities of IPv6 extension header processing which has much effect on the deployment of these features. This document analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. |
| | General Source Address Validation Capabilities |
| |
| | draft-huang-savnet-sav-table-08.txt |
| | Date: |
10/12/2024 |
| | Authors: |
Mingqing(Michael) Huang, Weiqiang Cheng, Dan Li, Nan Geng, Mingxing Liu, Li Chen, Changwang Lin |
| | Working Group: |
Individual Submissions (none) |
|
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. |
| | BFD Extension for DetNet Remote Defect Indication (RDI) |
| |
| | draft-huang-detnet-rdi-02.txt |
| | Date: |
10/10/2024 |
| | Authors: |
Hongyi Huang, Li Zhang, Tianran Zhou, Jing Gao |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. |
| | 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). |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-liu-sidrops-rtr-yang-06.txt |
| | Date: |
21/10/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). |
| | Reliability Considerations of Path-Aware Semantic Addressing |
| |
|
Path-Aware Semantic Address (PASA), proposes to algorithmically assign addresses to nodes in a 6lo environment so to achieve stateless forwarding, hence, allowing to avoid using a routing protocol. PASA is more suitable for stable and static wireline connectivity, in order to avoid renumbering due to topology changes. Even in such kind of scenarios, reliability remains a concern. This memo tackles specifically reliability in PASA deployments, analyzing possible broad solution categories to solve the issue. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | SR Policy Group |
| |
| | draft-cheng-spring-sr-policy-group-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Weiqiang Cheng, Jiang Wenying, Changwang Lin, Yuanxiang Qiu, Yawei Zhang, Ran Chen, Yanrong Liang |
| | Working Group: |
Individual Submissions (none) |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR policy and SR Policy Group to provide best practice cases for operators |
| | Echo Request/Reply for DetNet Capability Discovery |
| |
|
This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions. |
| | ISP Dual Queue Networking Deployment Recommendations |
| |
|
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores the potential implications of those decisions and makes recommendations that can help drive adoption and acceptance of L4S and NQB. |
| | BGP over QUIC |
| |
| | draft-retana-idr-bgp-quic-06.txt |
| | Date: |
07/01/2025 |
| | Authors: |
Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. |
| | A Taxonomy of Internet Consolidation |
| |
|
This document contributes to the ongoing discussion surrounding Internet consolidation. At recent IETF meetings discussions about Internet consolidation revealed that different perspectives gave completely different views of what consolidation means. While we use the term consolidation to refer to the process of increasing control over Internet infrastructure and services by a small set of organizations, it is clear that that control is expressed through economic, network traffic and protocol concerns. As a contribution to the discussion surrounding consolidation, this document attempts to provide a taxonomy of Internet consolidation with the goal of adding clarity to a complex discussion. |
| | INIT Forwarding for the Stream Control Transmission Protocol |
| |
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. |
| | Identity for E2E-Secure Communications |
| |
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than configuration. This document describes the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | The "dereferenceable identifier" pattern |
| |
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. // The present revision -04 includes a few clarifications. |
| | Flag-based MPLS Network Actions (MNA) for On-Path Telemetry |
| |
|
This document describes the support of two flag-based variants of on- path Telemetry techniques, Postcard-Based On-Path Telemetry (PBT) and Alternate Marking (AM), as MPLS Network Actions (MNA)for OAM in MPLS networks. The scheme only uses a few bits in the MNA header opcode dedicated for the flag-based actions. |
| | 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). |
| | Testing async submission |
| |
|
This draft is submitted only to test the async api submission endpoint |
| | The Gordian Envelope Structured Data Format |
| |
|
Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. |
| | 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. |
| | An Ontology for RFCs |
| |
|
This document defines an ontology that describes the specifications published by the RFC Editor, together with ancillary documents. |
| | Tactical Traffic Engineering (TTE) |
| |
| | draft-li-rtgwg-tte-02.txt |
| | Date: |
03/12/2024 |
| | Authors: |
Colby Barth, Tony Li, Andy Smith, Bin Wen, Luay Jalil |
| | Working Group: |
Individual Submissions (none) |
|
Conventional traffic engineering approaches for resource management used by RSVP-TE and SR-TE often leverage estimates of the ingress traffic demands, during path placement. Unforeseen and/or dynamic events, can skew these estimates by significant enough margins to result in unexpected network congestion. Recomputed paths that address the new demands may take a considerable amount of time, leaving the network in a sub-optimal state for far too long. This document proposes one mechanism that can avert congestion on a real-time basis. |
| | 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. |
| | Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | 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. |
| | Computerate Specification |
| |
|
This document specifies computerate specifications, which are the combination of a formal and an informal specification such as parts of the informal specification are generated from the formal specification. |
| | Compressed SID (C-SID) for SRv6 SFC |
| |
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming. |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, which we call timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes RFC 9231. |
| | IP Addressing with References (IPREF) |
| |
|
IP addressing with references, or IPREF for short, is a method for end-to-end communication across different address spaces normally not reachable through native means. IPREF uses references to addresses instead of real addresses. It allows to reach across NAT/NAT6 and across protocols IPv4/IPv6. It is a pure layer 3 addressing feature that works with existing network protocols. IPREF forms addresses (IPREF addresses) made of context addresses and references. These IPREF addresses are publishable in Domain Name System (DNS). Any host in any address space, including behind NAT/ NAT6 or employing different protocol IPv4/IPv6, may publish IPREF addresses of its services in DNS. These services will be reachable from any address space, including those running different protocol IPv4/IPv6 or behind NAT/NAT6, provided both ends support IPREF. IPREF is especially useful for transitioning to IPv6 or for operating networks with a mix of IPv4/IPv6. |
| | Managing CBOR codepoints in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | Distribution of SR P2MP Policies and State using BGP-LS |
| |
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. |
| | Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) |
| |
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. |
| | Abstract |
| |
|
This document introduces the Shang Mi(SM) cryptographic algorithm for openpgp protocol. |
| | CDDL models for some existing RFCs |
| |
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. |
| | Abstract |
| |
|
This document describes how to use a newly added message digest algorithm "SM3" in the TSIG protocol. It can be used to calculate the digest for the TSIG key by using a hash function. This document details the supplementation of the SM3 algorithm in TSIG. |
| | EAT Attestation Results |
| |
| | draft-fv-rats-ear-05.txt |
| | Date: |
06/02/2025 |
| | Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | the extensions of BGP-LS to carry security capabilities |
| |
|
As users' traffic faces more unpredictable attacks during transmission, there are more and more end-users now need high security data transmission guarantee, they need ISPs to provide security protection capabilities on the data forwarding path, but it is very difficult for operators to manage the security attributes of nodes through control surfaces. ISPs need to have real-time awareness of the security capabilities available in the network, then form a security capability map, finally provide security protection for users at the routing level. The goal of this draft is to collect the security capabilities of nodes, which will be one of the factors to form the routing topology, and use the routing programming capabilities to form a secure routing path. The security capability includes healthy information(such as the device software is up-to-date), security service information, device information(such as the manufacturer information of the equipment). The BGP-LS protocol is extended to carry the security capabilities of the node. The controller collects topology information, forms a topology path with security capabilities according to security requirements, and supports SRv6 path sending to execute node forwarding through programming. |
| | IGP Color-Aware Shortcut |
| |
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document specifies the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. |
| | Network Proactive Defense based on Source Address Validation |
| |
|
Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. |
| | dCBOR: A Deterministic CBOR Application Profile |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The CBOR Common Deterministic Encoding (CDE) Internet Draft builds on this by specifying a baseline for application profiles that wish to implement deterministic encoding with CBOR. The present document provides an application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding based on CDE for a variety of applications wishing an even narrower and clearly defined set of choices. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. To avoid YANG non-backward compatible change restrictions, the YANG module will have desigination ietf-vrrp-2.yang rather than ietf-vrrp.yang. This document obsoletes RFC 8347. |
| | Simplified MVPN for BIER and IR |
| |
|
Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution. |
| | Mobility Procedures in Presence of Unknown MAC Route |
| |
|
The Interconnect Solution for Ethernet VPN defines Unknown MAC (Media Access Control) Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is an overlay network for such interconnects. This scenario impacts MAC mobility procedures and needs to be addressed. This document describes additional changes and enhancements required for MAC mobility procedures when using UMR.. |
| | The DNSCrypt protocol |
| |
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/. Source for this draft and an issue tracker can be found at https://github.com/DNSCrypt/dnscrypt-protocol. |
| | BGP extensions for BIER-TE |
| |
|
"Tree Engineering for Bit Index Explicit Replication" (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. This document describes BGP extensions for advertising the BIER-TE specific information. |
| | Source IPv6 Address Programmability |
| |
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information |
| | Supplement of BGP-LS Distribution for SR Policies and State |
| |
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags are introduced in SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-jags-mpls-ps-mna-hdr-04.txt |
| | Date: |
19/12/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". |
| | On the Effects of Internet Consolidation |
| |
|
This document contributes to the continuing discussion on Internet consolidation. Over the last several years there have been many types of discussions around consolidation at a technical level, an economic or market level and also at an engineering level. This document aims to discuss recent areas of Internet consolidation and provide some suggestions for advancing the discussion. |
| | Extensible Simple Authentication and Security Layer (SASL) |
| |
| | draft-melnikov-sasl2-02.txt |
| | Date: |
02/12/2024 |
| | Authors: |
Dave Cridland, Thilo Molitor, Matthew Wild, Alexey Melnikov |
| | Working Group: |
Individual Submissions (none) |
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. |
| | EVPN Inter-Domain Option-B Solution |
| |
|
An EVPN Inter-Domain interconnect solution is required if two or more sites of the same Ethernet Virtual Private Network (EVPN) are attached to different IGP domains or Autonomous Systems (AS), and they need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for such EVPN connectivity. While multiple documents refer to this type of interconnect solution and specify different aspects of it, there is no document that summarizes the impact of the Inter-Domain Option-B connectivity in the EVPN procedures. This document does not specify new procedures but analyses the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the described issues. Those solutions are based on either other specifications or based on local implementations that do not modify the end-to-end EVPN control plane. |
| | Merkle Tree Certificates for TLS |
| |
|
This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post- quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) |
| |
| | draft-dong-pce-pcep-nrp-03.txt |
| | Date: |
05/01/2025 |
| | Authors: |
Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. |
| | SID as source address in SRv6 |
| |
|
In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. |
| | Security Considerations for Tenant ID and Similar Fields |
| |
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| | 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. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | 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. |
| | Design analysis of methods for distributing the computing metric |
| |
|
This document analyses different methods for distributing the computing metrics from service instances to the ingress router. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Computing-Aware Traffic Steering Working Group mailing list (cats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cats/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-cats-method-analysis. |
| | Structured Connection ID Carrying Metadata |
| |
|
This document describes a mechanism to carry the metadata in the QUIC connection ID to communicate with the intermediary. |
| | BGP Extensions for Source Address Validation Networks (BGP SAVNET) |
| |
| | draft-geng-idr-bgp-savnet-04.txt |
| | Date: |
11/10/2024 |
| | Authors: |
Nan Geng, Zhenbin Li, Zhen Tan, Mingxing Liu, Dan Li, Fang Gao |
| | Working Group: |
Individual Submissions (none) |
|
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. |
| | One Administrative Domain using BGP |
| |
| | draft-uttaro-idr-bgp-oad-05.txt |
| | Date: |
07/01/2025 |
| | Authors: |
Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). |
| | Service Interworking between SRv6 |
| |
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
| |
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. RFC Editor: Please replace YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. Please remove this note. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. |
| | EVPN First Hop Security |
| |
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures for Ethernet VPN (EVPN) will distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi-homing. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | Low Overhead Media Container |
| |
| | draft-mzanaty-moq-loc-04.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Mo Zanaty, Suhas Nandakumar, Peter Thatcher |
| | Working Group: |
Individual Submissions (none) |
|
This specification describes a media container format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT) [MoQTransport], with the goal of it being a low-overhead format. It further defines the LOC Streaming Format for the MOQ Common Catalog format [MoQCatalog] for publishers to annouce and describe their LOC tracks and for subscribers to consume them. The specification also provides examples to aid application developers for building media applications over MOQT and intending to use LOC as the streaming format. |
| | Aircraft to Anything AdHoc Broadcasts and Session |
| |
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. |
| | Efficient Air-Ground Communications |
| |
|
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery. |
| | OSPF Adjacency Suppression |
| |
|
This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. |
| | Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| | BFD Path Consistency over SR |
| |
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy |
| | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| | draft-sajassi-bess-rfc8317bis-03.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger |
| | Working Group: |
Individual Submissions (none) |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. |
| | RFC Style Guide |
| |
| | draft-rpc-rfc7322bis-02.txt |
| | Date: |
24/01/2025 |
| | Authors: |
Sandy Ginoza, Jean Mahoney, Alice Russo |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide". Note: This draft is being developed and discussed in the GitHub repo , but any substantive change should be discussed on . |
| | Purge Originator Identification for OSPF |
| |
|
In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. |
| | Galois Counter Mode with Strong Secure Tags (GCM-SST) |
| |
|
This document defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm. GCM-SST can be used with any keystream generator, not just 128-bit block ciphers. The main differences from GCM are the use of an additional subkey H_2, the derivation of fresh subkeys H and H_2 for each nonce, and the replacement of the GHASH function with the POLYVAL function from AES-GCM-SIV. This enables truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, which are significant security improvements over GCM. GCM-SST is designed for security protocols with replay protection and addresses the strong industry demand for fast encryption with minimal overhead and high security. This document registers several instances of GCM-SST using Advanced Encryption Standard (AES) and Rijndael-256. |
| | 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. |
| | Enforcing end-to-end delay bounds via queue resizing |
| |
|
This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. |
| | 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. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-yao-regext-epp-quic-03.txt |
| | Date: |
30/09/2024 |
| | Authors: |
Jiankang Yao, Hongtao Li, Man Zhang, Dan Keathley, James Gould |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. |
| | 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. One of the key technologies is to accurately obtain the cyclic mapping relationship between adjacent nodes and the packets can achieve the end-to-end deterministic forwarding. This draft describes the method for nodes to learn the cycle mapping relationship through sending learning messages. |
| | 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. |
| | A Mechanism for Encoding Differences in Paired Certificates |
| |
|
This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to construct the paired certificate and perform certification path validation using the constructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. |
| | Signaling In-Network Computing operations (SINC) |
| |
| | draft-lou-rtgwg-sinc-03.txt |
| | Date: |
15/09/2024 |
| | Authors: |
Zhe Lou, Luigi Iannone, Yizhou Li, Zhangcuimin, Kehan Yao |
| | Working Group: |
Individual Submissions (none) |
|
This memo introduces "Signaling In-Network Computing operations" (SINC), a mechanism to enable signaling in-network computing operations on data packets in specific scenarios like NetReduce, NetDistributedLock, NetSequencer, etc. In particular, this solution allows to flexibly communicate computational parameters, to be used in conjunction with the payload, to in-network SINC-enabled devices in order to perform computing operations. |
| | WARP Streaming Format |
| |
|
This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. |
| | 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. |
| | 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. |
| | WBA OpenRoaming Wireless Federation |
| |
| | draft-tomas-openroaming-04.txt |
| | Date: |
07/01/2025 |
| | Authors: |
Bruno Tomas, Mark Grayson, Necati Canpolat, Betty Cockrell, Sri Gundavelli |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. |
| | RIFT extensions for SRv6 |
| |
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the RIFT extensions required to support Segment Routing over the IPv6 data plane (SRv6). |
| | Intel Profile for Remote Attestation |
| |
|
This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes apticulareplication of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and 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 and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers. |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding delay factors, which are functions of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to SCION- capable endpoints that can choose between multiple path options, enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The main goal of the SCION Control Plane is to create and manage path segments which can then be combined into forwarding paths to transmit packets in the data plane. This document discusses how path exploration is realized through beaconing and how path segments are created and registered. Each SCION Autonomous System (AS) can register segments according to its own policy and can specify which path properties and algorithm(s) to use in the selection procedure. The document also describes the path lookup process whereby endpoints obtain path segments - a fundamental building block for the construction of end-to-end paths. |
| | BGP Route Broker for Hyperscale SDN |
| |
|
This document describes an optimized mechanism for BGP route reflection, known as BGP route broker. It aims to utilize the BGP- based IP VPN as an overlay routing protocol in a scalable manner, specifically for hyperscale data center network virtualization environments, commonly referred to as Software-Defined Network (SDN) environments. |
| | Inter-domain Source Address Validation based on AS relationships |
| |
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships. It mainly describes this method from five aspects: the research background in related fields, introduction to the AS relationship classification and acquisition methods, the SAV system's architecture, typical use cases, and considerations on deployability. |
| | Using onion routing with CoAP |
| |
|
The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and of clients similar to how Tor (The Onion Router) enables it for TCP-based protocols. |
| | HPCC++: Enhanced High Precision Congestion Control |
| |
| | draft-miao-ccwg-hpcc-03.txt |
| | Date: |
06/01/2025 |
| | Authors: |
Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman |
| | Working Group: |
Individual Submissions (none) |
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. |
| | Inband Telemetry for HPCC++ |
| |
| | draft-miao-ccwg-hpcc-info-04.txt |
| | Date: |
06/01/2025 |
| | Authors: |
Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman |
| | Working Group: |
Individual Submissions (none) |
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. |
| | Routing mechanism in Dragonfly Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing routing mechanism in dragonfly networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | Ping Path Consistency over SRv6 |
| |
|
In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. |
| | Raytime: Validating token expiry on an unbounded local time interval |
| |
|
When devices are deployed in locations with no real-time access to the Internet, obtaining a trusted time for validation of time limited tokens and certificates is sometimes not possible. This document explores the options for deployments in which the trade-off between availability and security needs to be made in favor of availability. While considerations are general, terminology and examples primarily focus on the ACE framework. |
| | Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism |
| |
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). |
| | 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. |
| | Validity of SR Policy Candidate Path |
| |
|
An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active (i.e., installed in forwarding and usable for steering of traffic). Each CP in turn may have one or more SID-List of which one or more may be active; when multiple SID-List are active then traffic is load balanced over them. However, a candidate path is valid when at least one SID-List is active. This candidate path validity criterion cannot meet the needs of some scenarios. This document defines the new candidate path validity criterion. |
| | Microloop Prevention in a Hierarchical Segment Routing Solution for CATS |
| |
|
Considering computing and networking is quite different in terms of resource granularity as well as their status stability, a hierarchical segment routing is proposed and introduced as an end-to- end CATS process. However, it brings about potential problems as illustrated in [I-D.yuan-cats-end-to-end-problem-requirement]. In order to solve the mentioned problems and to improve and perfect a hierarchical solution, corresponding aggregation methods are discussed and hierarchical entries are proposed in this draft. |
| | Validity of SR Policy Candidate Path |
| |
|
This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy. |
| | YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) |
| |
| | draft-li-savnet-sav-yang-05.txt |
| | Date: |
03/09/2024 |
| | Authors: |
Dan Li, Fang Gao, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. |
| | Views and View Addresses for Secure Asset Transfer |
| |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to-end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. |
| | Protocol for Requesting and Sharing Views across Networks |
| |
| | draft-ramakrishna-satp-data-sharing-03.txt |
| | Date: |
22/01/2025 |
| | Authors: |
Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy |
| | Working Group: |
Individual Submissions (none) |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. |
| | Agreements To Fix Forwarding |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | BGP Attribute Escape |
| |
|
BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact. |
| | BGP SR Policy Extensions for Path Scheduling |
| |
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. However, more and more cases require path scheduling to improve the network availability and resource utilization. This document proposes extensions to BGP SR Policy to indicate the scheduling time of each candidate path(segment list) and its associated attributes. |
| | IGP Prefix Independent Convergence |
| |
|
In many cases, a large number of routes can be reached by multiple next hops. When a link fails, route calculation needs to be performed and a new reachable path needs to be calculated. If all routes are re-calculated and refreshed, the calculation time increases linearly as the number of routes increases, resulting in a long time for route convergence. This document describes an architecture where the number of prefixes is independent. This architecture allows routes to be recalculated when paths change, regardless of the number of IGP routes. |
| | Advertisement of Candidate Path Validity Control Parameters using BGP-LS |
| |
|
This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc. |
| | SAVI in an EVPN network |
| |
|
Source Address Validation procedures have been specified in the SAVI Working Group and provide a set of mechanisms and state machines to verify Source Address ownership. The main mechanisms are described in RFC6620 and RFC7513. RFC7432 and furthermore RFC9161 specify how an EVPN network could learn and distribute IP addressess. RFC9161 describes a mechanism by which the PE can proxy some ND messages based on this information. In this document, we review how these two sets of specifications and underlying mechanisms can interact to provide Source Address Validation in an EVPN network. |
| | Advertise NRP Group extensions for IGP |
| |
|
Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes,structures, and functions so that each slice can be dedicated to specific services or customers. A Network Resource Partition (NRP) is a collection of resources in the underlay network. Each NRP is used as the underlay network construct to support one or a group of IETF network slice services. This document describes an IGP mechanism that is used to advertise a large number of NRPs into a smaller number of NRP groups. |
| | EVPN Anycast Multi-Homing |
| |
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function addresses the load balancing of unicast packets from remote Network Virtualization Edge (NVE) devices to the NVEs that are multi-homed to the same CE, irrespective of the learning of the CE's MAC/IP information on the NVEs. This document describes an optional optimization of the EVPN multi-homing Aliasing function - EVPN Anycast Multi-homing - that is specific to the use of EVPN with NVO3 tunnels (i.e., IP tunnels) and, in typical Data Center designs, may provide some benefits that are discussed in the document. |
| | The Secondary Label and its applications |
| |
|
This draft utilizes the concept of a secondary label to solve few cases in L3VPN Deployments.In BGP VPN networks, BGP speakers associate a local MPLS label when the next-hop is reset and advertise that label to other peers. The receiving peer installs this "received" label in the forwarding and forwards traffic to the sending router using this label. In some deployments, there arises need where a different label is required to be sent. We illustrate with two use-cases. This draft presents a method where this label is encoded in a newly defined attribute that is advertised with the BGP updates targeting these specified use-cases |
| | PCEP extension to support Candidate Paths validity |
| |
|
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy. |
| | Computing-Aware Traffic Steering (CATS) Using Segment Routing |
| |
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifier and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. |
| | 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 the Stateless Hash-Based Digital Signature Algorithm (SLH- DSA) specified in the draft FIPS 205. 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. |
| | Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP) |
| |
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 6083. DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions. |
| | MIMI Portability |
| |
|
This document describes MIMI Portability mechanisms. |
| | MIMI Attachments |
| |
|
This document describes MIMI Attachments. |
| | Maintaining Protocols Using Grease and Variability |
| |
|
Long-term interoperability of protocols is an important goal of the network standards process. Deployment success can depend on supporting change, which can include modifying how the protocol is used, extending the protocol, or replacing the protocol. This document presents concepts, considerations, and techniques related to protocol maintenance, such as greasing or variability. The intended audience is protocol designers and implementers. |
| | Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies |
| |
|
The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. |
| | Privacy Pass Token Expiration Extension |
| |
|
This document describes an extension for Privacy Pass that allows tokens to encode expiration information. |
| | Packed CBOR: Table set up by reference |
| |
|
Packed CBOR is a compression mechanism for Concise Binary Object Representation (CBOR) that can be used without a decompression step. This document introduces a means for setting up its tables by means of dereferenceable identifiers, and introduces a pattern of using it without sending long identifiers. |
| | The Restatement Anti-Pattern |
| |
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. |
| | CBOR: On Deterministic Encoding and Representation |
| |
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides additional information about use cases, deployment considerations, and implementation choices for Deterministic Encoding and Representation. |
| | ESP Echo Protocol |
| |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | Hybrid IANA Registration Policy |
| |
|
The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies. |
| | Route Target ORF |
| |
|
This document defines a new Outbound Router Filter (ORF) type for BGP, referred to as "Route Target Outbound Route Filter", that can be used to perform route target based route filtering. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | First-Party Approved Third-Party Certifications in OpenPGP |
| |
|
An OpenPGP certificate can grow in size without bound when third- party certifications are included. This document describes a way for the owner of the certificate to explicitly approve of specific third- party certifications, so that relying parties can safely prune the certificate of any unapproved certifications. |
| | Signaling MNA Capability Using IGP and BGP-LS |
| |
|
This document defines a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS). |
| | SW103K PROTOCOL |
| |
|
What Problems Does This Protocol Solve? The SW103k protocol addresses several challenges that arise when transporting data over networks with limited bandwidth, latency constraints, and data integrity concerns. Specifically, it provides a compression and decompression mechanism designed to: Optimize Bandwidth Utilization: In environments where bandwidth is limited, such as IoT networks, satellite communications, and mobile data transfers, SW103k reduces the amount of data sent over the wire by compressing data in transit, thus saving bandwidth. Improve Data Transfer Speeds: By compressing data before transmission, the protocol reduces the volume of data that needs to be transferred, which improves transfer speeds, especially in networks where bandwidth is a bottleneck. Ensure Data Integrity: In addition to compression, SW103k integrates error- checking mechanisms that ensure data arrives intact. This helps mitigate issues in unreliable network conditions where packet loss or corruption might occur. Security Considerations: The protocol incorporates optional encryption to provide confidentiality during data transmission. This is especially useful in scenarios where sensitive data needs to be transferred, like financial transactions or health data over potentially insecure networks. How Does This Protocol Work? The SW103k protocol operates in a client-server architecture, where the sender (client) compresses the payload using a predefined compression algorithm before transmitting it to the receiver (server). The receiver then decompresses the data back into its original form. Key Components: Compression Algorithm: SW103k uses a hybrid compression algorithm combining LZ77 and Huffman encoding, ensuring efficient data compression with minimal overhead. The protocol negotiates the compression parameters (e.g., window size) at the start of each connection. Decompression Mechanism: The receiver is responsible for decompressing the data using the same parameters agreed upon during the initial handshake. The decompression process is optimized for low-latency environments to ensure the data is available with minimal delay. Transport Layer: SW103k functions over standard transport layers such as TCP or QUIC, and adds a lightweight layer that manages compression, decompression, and error-checking. The protocol header contains metadata about the compression type and error-checking mechanism used. Error Checking: SW103k includes a checksum or CRC32 in each transmission block, ensuring that data corruption can be detected and retransmitted if necessary. Comparison with Other Transport Protocols Compared to other transport protocols like TCP or QUIC, SW103k doesn’t replace them but adds an additional layer of compression and decompression to the transport process. Unlike raw TCP or QUIC, which primarily focus on connection reliability and speed, SW103k introduces bandwidth optimization through compression, which makes it particularly useful in constrained environments. Here’s how SW103k compares with other protocols: TCP: TCP provides reliable transmission, but it does not natively compress data. While you can use application-layer compression with TCP, SW103k integrates compression at the transport layer, optimizing both compression and transmission. QUIC: QUIC focuses on speed and low-latency transmissions, especially over unreliable networks. SW103k could potentially be layered on top of QUIC to introduce compression, making it useful in high-latency networks like mobile or satellite. TLS: TLS ensures security over transmission but doesn’t compress data. SW103k can work with TLS, where compressed data is first encrypted before being transmitted, adding an additional layer of bandwidth efficiency. SCTP: Like TCP, SCTP focuses on reliability, especially for message-based communications. SW103k could work with SCTP when reliability and bandwidth optimization are both critical. Why Choose SW103k Over Existing Protocols? SW103k could be chosen over existing protocols when: Bandwidth Optimization is Critical: In environments like IoT networks, satellite communications, or mobile data transfer, where bandwidth is expensive or limited, SW103k reduces the overall data transferred by compressing the payload before transmission. Minimal Processing Overhead: SW103k has been designed to offer high levels of compression with low computational overhead, making it ideal for low- power devices or systems with limited resources. Easy Integration with Existing Protocols: SW103k is designed to work alongside existing transport protocols (e.g., TCP, QUIC) without needing major architectural changes. It acts as a lightweight add-on for compression and decompression, simplifying adoption for legacy systems. Security Issues Raised by Using This Protocol Using the SW103k protocol introduces a few potential security considerations: Compression-related Attacks: Compression algorithms may be susceptible to attacks such as the CRIME or BREACH attacks, which exploit the predictable nature of compressed data. Implementing padding or randomized inputs to the compression process could help mitigate these risks. Data Integrity and Tampering: Since the protocol involves compressing and decompressing data, there's a risk that data might be tampered with during transmission. SW103k addresses this by incorporating checksum or CRC32 mechanisms to verify the integrity of each transmission block. Encryption Considerations: If sensitive data is being transmitted using SW103k, the protocol needs to ensure that the compression process doesn't leak information about the original data. It’s recommended that data be encrypted before compression or using TLS in conjunction with SW103k for secure transmissions. Denial-of-Service (DoS) Vulnerabilities: Malicious users could flood the server with decompression requests, consuming significant CPU resources. Implementing rate limiting or requiring authenticated connections before processing requests can reduce the attack surface. Concrete Examples of What is Missing When I refer to the current document not containing anything concrete, I mean that the draft lacks crucial technical details and implementation guidance that protocol implementers or reviewers need to understand the protocol’s purpose and function. For example: Detailed Algorithm: Instead of just saying “SW103k compresses data,” a concrete description would include the actual algorithm (e.g., how the hybrid of LZ77 and Huffman encoding works) and pseudocode to explain how compression and decompression happen. Message Formats: In protocols like HTTP/2 or QUIC, message formats are clearly defined. Each byte or bit has a meaning in the headers, body, and control information. SW103k should include message diagrams showing what the protocol header looks like, how metadata is transmitted, etc. State Machine or Flow Diagrams: Many transport protocols include flow diagrams showing how the protocol handles different network events (e.g., connection initiation, packet retransmission). SW103k should include this to illustrate the typical lifecycle of a connection. Code Examples: Providing actual working code that developers could use to implement SW103k would be useful. This could be a Python or C library that demonstrates how compression is performed and how the protocol interacts with the transport layer. Conclusion: Actionable Next Steps for Internet Draft To move forward with SW103k as an Internet Draft for the IETF: Develop a Detailed Specification: Include the detailed design and behavior of the protocol, including the compression algorithm, transport layer interaction, and flow control. Provide Concrete Examples: Add sample pseudocode or protocol header diagrams that illustrate how the protocol works in practice. Security Considerations: Detail the potential risks (e.g., CRIME/ BREACH attacks) and provide mitigation strategies to secure the protocol. Test Cases and Implementation: Provide a reference implementation or a set of test cases for developers to try out the protocol in different environments. |
| | Experiment with Unicode characters in xml2rfc |
| |
|
This draft is an experiment to explore what happens when various Unicode characters are on an Internet-Draft and how xml2rfc handles that. |
| | Intelligent Routing Method of SR Policy |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes an intelligent routing method for SR Policy based on network quality in MPLS and IPv6 environments. |
| | Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. Up to now, communications have been done on a layer-2 point to point basis, with sometimes the use of relays, therefore no layer-3 networking was possible. RFC4838 reports an assessment done around 25 years ago concluding that the IP protocol stack was not suitable for deep space networking. This result lead to the definition of a new protocol stack based on a store-and-forward paradigm implemented in the Bundle Protocol(BP). More recently, space agencies are planning to deploy IP networks on celestial bodies, such as Moon or Mars, ground, and vicinity. This document revisits the initial assessment of not using IP and provides solution paths to use the IP protocol stack, from IP forwarding to transport to applications to network management, in deep space communications. |
| | Terminal-based joint selection and configuration of MEC host and DETNET-RAW network |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | Extensions to enable wireless reliability and availability in multi-access edge deployments |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | MIPv6 DETNET-RAW mobility |
| |
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| | DetNet multidomain extensions |
| |
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. |
| | 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. |
| | PREOF IOAM Method for Deterministic Network Service Sub-layer |
| |
|
This document proposes an active IOAM method to PREOF monitor and troubleshoot for Deterministic Networking (DetNet) in its service sub-layer. The method uses a special PREOF-TRACE message to collect multiple types of information from the target flow's PREOF entities and to record them in the packet, and uses a PREOF-RESPONCE message to feed them back to the head node. It assists the DetNet to monitor and maintain the PREOF for the traffic flow. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| | 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. |
| | Resource Guarantee for SRv6 Policies |
| |
|
This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list , the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. |
| | SCION Data Plane |
| |
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION Data Plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. |
| | External Keys For Use In Internet X.509 Certificates |
| |
|
Many of the post quantum cryptographic algorithms have large public keys. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and algorithms for referencing external public key data by hash, and location, for example URL. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. |
| | BGP Operations for Inter-domain SAVNET |
| |
|
This document attempts to present BGP policy-based solution for source address validation in inter-domain networks. |
| | Information Awareness System for Computing-Aware Service Function Chain (IAS-CASFC): Security Service Aspect |
| |
|
This document describes the Information Awareness System of the Computing-Aware Service Function Chain (ISA-CASFC) from the security service aspect, including the system architecture, network, and computing information details. The SFC enables traffic to pass through the ordered Network Security Function (NSF) path, enabling end-to-end security services. Differences in the available network and computing resources cause performance differences between NSF instances deployed on different service sites. It can be seen that the routing decision on NSF instances will affect the quality of the security service. Therefore, it is necessary to implement the CA-SFC to ensure the quality of security service. This document extends the CATS framework and the CATS Computing and Network Information Awareness (CNIA) architecture for CA-SFC, and describes the network and computing information content for security service. |
| | OpenPGP HTTP Keyserver Protocol |
| |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | BGP Extension for Distributing CP Threshold Constraints of SR Policy |
| |
|
This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. |
| | PCEP Extensions to Support Signaling Candidate Path Threshold Constraints of SR Policy |
| |
|
This document defines the extensions of PCEP to signal the threshold and metric constraint parameters of candidate paths for SR Policy to support flexible path selection. |
| | The Mastic VDAF |
| |
| | draft-mouris-cfrg-mastic-04.txt |
| | Date: |
23/01/2025 |
| | Authors: |
Hannah Davis, Dimitris Mouris, Christopher Patton, Nektarios Tsoutsos |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Mastic, a two-party VDAF for the following secure aggregation task: each client holds an input string and an associated weight, and the data collector wants to aggregate the weights of all clients whose inputs begin with a prefix chosen by the data collector. This functionality enables two classes of applications. First, it allows grouping metrics by client attributes without revealing which clients have which attributes. Second, it solves the weighted heavy hitters problem, where the goal is to compute the subset of inputs that have the highest total weight. |
| | PFM-SD extension for EVPN multi-homing |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services and in service provider (SP) applications for next-generation virtual private LAN services. EVPN defines sets of procedures to achieve multihoming between peers. When the multicast source is protected by EVPN multihoming for redundancy and multicast receivers are present behind PIM network, there are cases where traffic blackholes. PIM Flooding Mechanism (PFM) and Source Discovery (SD) define new flood mechanisms in PIM domain to carry information about source and group. This draft defines the necessary extension to PFM-SD procedures to have seamless integration with EVPN supported multihoming. |
| | CDNI Metadata Expression Language |
| |
|
This document specifies the syntax and provides usage examples for an expression language to be used within Streaming Video Technology Alliance (SVTA)/Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| | CDNI Processing Stages Metadata |
| |
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| | BGP Flow Specification for Source Address Validation |
| |
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules. |
| | QUIC Address Discovery |
| |
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. |
| | EAT profile for Intel(r) Trust Domain Extensions (TDX) attestation result |
| |
|
Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. |
| | Recommendations for using Multiple IP Addresses in Benchmarking Tests |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | Reliability Framework for SRv6 Service Function Chaining |
| |
|
This document describes the framework for protection of service function chains in source routing networks. |
| | IGP Color-Aware Routing |
| |
| | draft-lin-lsr-igp-car-02.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| | YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
| |
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| | Per Resource Events |
| |
|
Per Resource Events is a minimal protocol built on top of HTTP that allows clients to receive notifications directly from any resource of interest. The Per Resource Events Protocol (PREP) is predicated on the idea that the most intuitive source for notifications about changes made to a resource is the resource itself. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative and recursive resolvers support both IPv4 and IPv6. This document obsoletes RFC3901. (if approved) Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/momoka0122y/draft-dnsop-3901bis. |
| | A Multiplane Architecture Proposal for the Quantum Internet |
| |
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. |
| | Extended Semantic Definition Format (SDF) for Digital Twin |
| |
|
An SDF specification can describe the definition of Things, i.e., physical objects and their associated interactions, and express the various information that is exchanged for these interactions. Therefore, the SDF format can be used to define the behavior of an object and its associated data model and interaction model in a digital twin system that includes the object as a component. In a digital twin system, interactions between physical and virtual objects, as well as interactions of objects existing in different digital twin systems, are performed over a network, making it important to provide location information of objects during interactions. This document specifies the extension of SDF to represent the location information of objects. |
| | SRH Reduction for SRv6 End.M.GTP6.E Behavior |
| |
|
Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. |
| | Requirements from Control and Management Viewpoint for Collective Communication Optimization |
| |
|
Collective communication optimization is crucial to improve the performance of distributed applications, due to that communication has become bottleneck to degrade applications with the growth of scale of distributed systems. The industry and academy has worked on proposing solutions to upgrade collective communication operations. However, there has been a problem of lacking for unified guidelines. This draft provide requirements on collective communication optimization from the control and management viewpoint. |
| | Ethernet VPN Signalling Extensions for Bit-stream VPWS |
| |
|
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). |
| | Enhanced Use Cases for Scaling Deterministic Networks |
| |
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video and intelligent computing, and outlines the common properties implied by these use cases. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The author (gratefully) accept pull requests. |
| | Opportunistic TCP-AO with TLS |
| |
| | draft-piraux-tcp-ao-tls-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. |
| | BGP over TLS/TCP |
| |
|
This document specifies the utilization of TCP/TLS to support BGP. |
| | BIER Loop Avoidance using Segment Routing |
| |
| | draft-liu-bier-uloop-05.txt |
| | Date: |
15/02/2025 |
| | 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. |
| | Adaptive Routing Notification |
| |
|
Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and/or improve transport reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, is growing popular in commodity data centers to dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, the sensing node can not only apply AR locally but also send the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the reported path. This document specifies Adaptive Routing Notification (ARN), a general mechanism to proactively disseminate congestion detection and congestion elimination information for remote nodes to perform re-routing policies. |
| | Problem Statement,Use Cases,and Requirements of Hierarchical SFC with Segment Routing |
| |
|
Hierarchical Service Function Chaining (hSFC) is a network service chaining method that utilizes a hierarchical structure to efficiently organize and manage service function chains, enhancing network performance and scalability. This document primarily describes the use case of hSFC, which is the security resource pool. It outlines the associated problem statement and requirements for the security resource pool. The document aims to assist in identifying candidate solution architectures and solutions. |
| | Post-Quantum Cryptography Recommendations for TLS-based Applications |
| |
|
Post-quantum cryptography presents new challenges for applications, end users, and system administrators. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and key supporting protocols such as DNS. |
| | Benchmarking Methodology for Reliable Transport Protocols in Integrated Space and Terrestrial Networks |
| |
|
This document defines the terminology and methodology for conducting performance benchmarking of the transport protocols for low-earth orbit satellite user terminals within emerging integrated space and terrestrial networks (ISTN). It encompasses the test environment setup and benchmarking methodology. The objective of this document is to enhance the applicability, repeatability, and transparency of performance benchmarking for reliable transport protocols (e.g. TCP and QUIC) in ISTNs. |
| | Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS) |
| |
|
BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. |
| | A Mechanism for X.509 Certificate Discovery |
| |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | Trust and security considerations for Structured Email |
| |
|
This document discusses trust and security considerations for structured email and provides recommendations for message user agents on how to deal with structured data in email messages. |
| | LDP Extensions to Support Private Line Emulation (PLE) |
| |
|
This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks. |
| | Kademlia-directed ID-based Routing Architecture (KIRA) |
| |
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA offers highly scalable zero-touch IPv6 connectivity, i.e., it can connect hundred thousands of routers and devices in a single network (without requiring any form of hierarchy like areas). It is self-organizing to achieve a zero-touch solution that provides resilient (control plane) IPv6 connectivity without requiring any manual configuration by operators. It works well in various topologies and is loop-free even during convergence. The architecture consists of the ID-based network layer routing protocol R²/Kad in its routing tier and a Path-ID-based forwarding tier. The topological independent IDs can be embedded into IPv6 addresses, so that KIRA provides zero-touch IPv6 connectivity between KIRA nodes. |
| | Centralized Anycast Gateway in Ethernet VPN(EVPN) |
| |
|
EVPN Integrated Routing and Bridging (IRB) fabrics provide a flexible and extensible method for Layer-2 and Layer-3 overlay network connectivity. [EVPN-IRB] defines operation for symmetric and asymmetric EVPN IRB using distributed anycast gateway architecture (DAG). In a DAG architecture, both bridging and first-hop routing functions for overlay subnets are located on leaf PEs, with first-hop routing provided by a distributed anycast gateway provisioned across the leaf PEs. This document describes an architecture and operation for EVPN Centralized Anycast Gateway (CAG), which allows the first- hop routing function for overlay subnets to be centralized on designated IRB GWs while the bridging function is still located on the leaf PEs. The documents also covers trade-offs of deploying a CAG as compared with DAG. It further describes operation for inter- op between CAG and DAG based EVPN-IRB network overlays. |
| | Joint Exposure of Network and Compute Information for Infrastructure-Aware Service Deployment |
| |
|
Service providers are starting to deploy computing capabilities across the network for hosting applications such as distributed AI workloads, AR/VR, vehicle networks, and IoT, among others. In this network-compute environment, knowing information about the availability and state of the underlying communication and compute resources is necessary to determine both the proper deployment location of the applications and the most suitable servers on which to run them. Further, this information is used by numerous use cases with different interpretations. This document proposes an initial approach towards a common exposure scheme for metrics reflecting compute and communication capabilities. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | BIER Anycast MPLS Label |
| |
|
This document provides a method to reduce packet loss when failures occur at BIER transit or egress nodes or link. |
| | Global Token Revocation |
| |
|
Global Token Revocation enables parties such as a security incident management tool or an external Identity Provider to send a request to an Authorization Server to indicate that it should revoke all of the user's existing tokens and require that the user re-authenticates before issuing new tokens. |
| | Usage specification of the otpauth URI format for TOTP and HOTP token generators |
| |
|
This document describes a foundational schema for the otpauth URI, utilized by TOTP (and/or HOTP) based authenticators. |
| | Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. |
| | SCIM Delta Query |
| |
|
This document defines extensions to the SCIM 2.0 protocol that enable clients to poll service providers for changes that have occurred since a delta (or watermark) token was issued by the service provider. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a symmetric digital identity authentication system that requires no federation of authentication domains. The main components of the authentication process between two entities are: 1. *Symmetric authentication protocol* - Both entities must recognize each other and are authenticated by their identity provider according to a symmetric message exchange scheme. It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - A special network dedicated to creating a protected environment for exchanging authentication messages between Identity Providers (IdPs) constitutes the infrastructure to avoid domain federation. 3. *Custodian concept* - IdPs are divided into two typologies to better protect personal data and link digital identity to physical one. A generic IdP (called trustee) to manage digital authentication only and a specific IdP (called custodian), with the legal right to process the individual's real data and under the control of country's authority, to manage the physical identity and the link with the digital one. |
| | RFC 3535,20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling |
| |
|
The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. |
| | Fully Adaptive Routing Ethernet using LSR |
| |
| | draft-xu-lsr-fare-03.txt |
| | Date: |
01/09/2024 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource- intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three- stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination over multiple equal-cost paths, based on network capacity and even congestion information along those paths. |
| | Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines a usage of Datagram Transport Layer Security (DTLS) 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP DTLS chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re- authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| | Guidance for HTTP Capsule Protocol Extensibility |
| |
|
This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. |
| | LibrePGP Message Format |
| |
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| | Path Tracing in SRv6 networks |
| |
| | draft-filsfils-ippm-path-tracing-02.txt |
| | Date: |
25/11/2024 |
| | 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. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3 and QUIC |
| |
|
This document 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. |
| | 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. |
| | 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 addresses for NLRI in RFC-4271 in the NEXT_HOP field and in RFC-4760 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. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. |
| | 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. |
| | CoAP in Space |
| |
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | NTS extensions for enabling pools |
| |
| | draft-venhoek-nts-pool-01.txt |
| | Date: |
03/11/2024 |
| | 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. |
| | Recursively Setting Attributes of Subdirectories and files |
| |
|
In the recent years, the concept of near-data computing has been widely recognized in storage architectures. The core idea is to process data nearby, reduce the overhead of network transmission, and utilize the computing capability of smart devices (such as intelligent NICs, smart SSDs, and DPUs). This reduces CPU and memory usage of clients (computing nodes) and improves data processing efficiency. This design idea is applied in NFSv4.2 or future NFS versions, such as Server-Side Copy, in which client sends the control command and the storage server copies data without transmitting between client and server. We are proposing a new mechanism for setting the attributes for all the files and directories in the parent directory, based on thes same thinking of the server side copy mechanism. Compared with traditional setting of attributes, data transmission over the network is reduced and the bandwidth resources are greatly released. |
| | 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. |
| | 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]. |
| | Definition for Aggregated BMP Route Monitoring Message |
| |
|
This document proposes an aggregated BMP route monitoring message. It can compress multiple BMP route monitoring messages into one aggregated BMP route monitoring message to reduce the amount of reported BMP route monitoring messages and reduce network overhead. This document updates RFC 7854 by adding new BMP Messages type. |
| | Clarification to processing Key Usage values during CRL validation |
| |
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. |
| | Intra-domain SAVNET Support via IGP |
| |
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. |
| | X-Wing: general-purpose hybrid post-quantum KEM |
| |
|
This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. |
| | Bicone Source Address Validation |
| |
|
The primary design goal of source address validation (SAV) is avoiding improper blocks (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter based on BGP updates, ROAs, and ASPAs related to the provider cone. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. |
| | Support of Observation Timestamp in YANG-Push Notifications |
| |
|
This document extends YANG-Push Notifications with the YANG objects observation timestamp and point-in-time for streaming update YANG- Push notifications. |
| | Paths Limit for Multiple Paths in BGP |
| |
|
This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. |
| | Mechanism to control jitter caused by policing in Detnet |
| |
|
This document presents a noble mechanism to eliminate jitter caused by policing delay in a network. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the DetNet flow. |
| | Safe(r) Limited Domains |
| |
|
There is a trend towards documents describing protocols that are only intended to be used within "limited domains". These documents often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains //perfectly// add filters at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses the concepts of "fail-open" versus "fail- closed" protocols for limited domains. It further specifies how to use layer-2 protocol identification mechanisms for designing limited domain protocols that are safer to deploy. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | 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, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | Asset Schema Architecture for Asset Exchange |
| |
|
A management architecture for asset schemas and profiles is needed to enable entities in the tokenized assets ecosystem to instantiate tokens within one or more asset networks. An asset network may be constrained to support only a select class or type of token to be present in the network. In the SATP protocol, the receiving gateway at the destination network is assumed in its preparatory stages to evaluate the transfer request of a tokenized asset from the sending gateway at the origin network. In order to evaluate the proposed transfer, the receiving gateway must have access to the asset definition schema upon which the token was based in the origin network. The current document discusses the management architecture for the asset definition schema and the schema-profiles derived from the definition schema. |
| | Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on ISO and Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms is ISO standardization and are mandatory for some scenario in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. |
| | NASR Use Case and Requirements |
| |
| | draft-liu-nasr-requirements-03.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Peter Liu, Luigi Iannone, Diego Lopez, Antonio Pastor, Meiling Chen, Li Su |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the use cases and requirements that guide the specification of a Network Attestation for Secure Routing framework (NASR). |
| | 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. |
| | Something Better Than Errata |
| |
|
This document outlines some ideas for a new errata handling policy that would (in the author's view) be better than current errata handling. This is for discussion and is not expected to become an RFC. |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices and under different network configurations and conditions. |
| | IPv4 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs for both existing Internetworking pathways and a new link model for the future. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. |
| | IPv6 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing only a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of- packets", while AJs offer essential operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Networking (DTN) link model. |
| | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
| |
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, and Classic McEliece. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-wiggers-hbs-state-01.txt |
| | Date: |
24/09/2024 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Individual Submissions (none) |
|
Stateful Hash-Based Signature Schemes (S-HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large- scale quantum computers. Unlike conventional stateless digital signature schemes, S-HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered. |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | 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. |
| | IPv6 Extended Fragment Header for IPv4 |
| |
|
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 adapting the IPv6 Extended Fragment Header for IPv4. |
| | Definition and Problem Statement of consistent inter-domain routing and forwarding |
| |
|
This document introduces what the forwarding consistency is and why forwarding inconsistency is prevalent in the Internet, describes the risks of forwarding inconsistency and defines the requiremenets for forwarding consistency. |
| | 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. |
| | A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET |
| |
|
This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter- domain SAV and is ready to establish neighbor relationship for preventing source address spoofing. |
| | Path-aware Remote Protection Framework |
| |
|
This document describes the framework of path-aware remote protection. |
| | Advertisement of SR Policy Flexible Candidate Path Selection Result using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the result of SR Policy flexible candidate path selection. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | Terminal Identity Authentication Based on Address Label |
| |
|
This document proposes an IPv6-based address label terminal identity authentication architecture, which tightly binds identity information to the source address of data packets. This approach enables hop-by- hop identity authentication while ensuring source address verification. The mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document details the implementation of address label authentication within the IPv6 extension header. |
| | ML-KEM for HPKE |
| |
|
This document defines Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) KEM options for Hybrid Public-Key Encryption (HPKE). ML-KEM is believed to be secure even against adversaries who possess a cryptographically-relevant quantum computer. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | Latency analysis of mobile transmission |
| |
|
Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. |
| | Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | Customer Experience Index for Evaluating Network Quality for Cloud Applications |
| |
| | draft-hz-ippm-cei-02.txt |
| | Date: |
18/10/2024 |
| | Authors: |
Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Xuesong Geng, Hongyi Huang, Tianran Zhou, Jian Ge, KE Ma, Ruihao Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network. |
| | The OID Directory: A Technical Roadmap |
| |
|
This I-D outlines a series of experimental standards documents which define the abstracts of the "OID Directory": a proposed philosophy and set of procedures used to facilitate the storage and management of the "OID tree" -- in part or in whole -- within an X.500/LDAP service implementation. |
| | The OID Directory: The Schema |
| |
|
In service to the "OID Directory" I-D series, this I-D extends schema definitions for use within an implementation of the Registration Authority Directory Information Tree. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DUA |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design strategies, requirements and procedures for the client component of the OID Directory Registration Authority client/server model. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DSA |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design considerations and basic requirements for the server component of the OID Directory Registration Authority client/server model. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DIT |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design strategies and requirements relating to the Registration Authority Directory Information Tree. See the RADIR I-D for a complete draft series manifest. |
| | Deterministic Routing Header |
| |
|
This document introduces a new IPv6 Routing Header used for deterministic forwarding wihch is generally a strict explicit path. This Routing Header will contain the decoupled topology instructions and deterministic forwarding resource indications. The target is low cost of encapasultion and less amount of allocated SIDs. |
| | Extended YANG Data Model for DOTS |
| |
|
With the development of DDoS defense technologies, the interfaces and parameters defined by DOTS are no longer sufficient to support the collaborative signaling required between DDoS mitigation systems. This document defines three YANG model to extend the data models of existing interfaces on the DOTS signaling and data channels, with the aim of supporting the transmission of necessary collaborative information between DDoS mitigation systems via DOTS and enabling efficient collaborative mitigation based on this information. |
| | No Further Fast Reroute for SRv6 Service SID |
| |
|
In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR flags for SRv6 Service SIDs in BGP messages. |
| | SRv6 Service SID Anycast Flag |
| |
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines the Anycast-flag for SRv6 Service SIDs carried in BGP messages. |
| | 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. |
| | Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | Advanced Professional Video |
| |
| | draft-lim-apv-03.txt |
| | Date: |
12/12/2024 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Individual Submissions (none) |
|
This document describes bitstream format of Advanced Professional Video and decoding process of it. |
| | The Asynchronous Remote Key Generation (ARKG) algorithm |
| |
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. |
| | Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications |
| |
| | draft-schott-sip-avors-02.txt |
| | Date: |
19/09/2024 |
| | Authors: |
Roland Schott, Michael Kreipl, Bastian Dreyer, Roland Jesske |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active UE (User Equipment) registrations on other SIP Proxies within the SIP voice architecture. The concept can be mapped on any architecture having a distributed structure and could work for different protocols. In this document, the concept is exemplary explained regarding an architecture for voice and could also be mapped on a 3GPP (3rd Generation Partnership Project) architecture. The AVORS concept increases service continuity, improves network resilience and offers savings potential. Additionally, this document gives an outlook regarding stateless voice architectures, load calculation aspects, and Service Based Interfaces (SBI) with session data base interworking. Security aspects are considered in the security chapter. As stated above the AVORS principle is not only limited to the SIP protocol and could be adopted by other protocols. |
| | Identity Assertion Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| | Documenting and Managing DNSSEC Algorithm Lifecycles |
| |
|
Cryptographic algorithms for DNSSEC go through multiple phases during their lifetime. They are created, tested, adopted, used, and deprecated over a period of time. This RFC defines phases for the DNSSEC algorithm lifecycle, and it defines the criteria for moving from one phase to the next. |
| | Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives |
| |
| | draft-havel-nmop-digital-map-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Olga Havel, Benoit Claise, Oscar de Dios, Ahmed Elhassany, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
This document shares experience in modelling Digital Map based on the IETF RFC 8345 topology YANG modules and some of its augmentations. The document identifies a set of open issues encountered during the modelling phases, the missing features in RFC 8345, and some perspectives on how to address them. For definition of Digital Map concepts, requirements and use cases please refer to the "Digital Map: Concept, Requirements, and Use Cases" document. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/OlgaHuawei. |
| | 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. |
| | Mobile User Plane Architecture for Distributed Mobility Management |
| |
| | draft-mhkk-dmm-mup-architecture-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Satoru Matsushima, Katsuhiro Horiba, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Jakub Horn |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case due to the DMM requirement, and is suitable for mobile services which require a large IP address space. |
| | Data Fields for Congestion Measurement |
| |
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement command in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, aids in effective load balancing, and simplifies network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. |
| | IPv6 Options for Congestion Measurement |
| |
|
The Congestion Measurement enables precise congestion control, aids in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document outlines how Congestion Measurement Data-Fields are encapsulated in IPv6. |
| | IKEv2 Support for Anti-Replay Status Notification |
| |
|
Although RFC 4302 and RFC 4303 don't prohibit using Extended Sequence Number (ESN) when the anti-replay function is not enabled, many IPsec implementations require ESN to be used only with anti-replay. Therefore, failing to negotiate the use of ESN when the anti-replay is disabled will cause the sequence numbers to exhaust rapidly in high-traffic-volume scenarios, leading to the frequent rekey of Child SAs. This document defines the REPLAY_PROT_AND_ESN_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peer of its replay protection status and capability of using ESN without anti-replay when creating the Child SAs, to address the above problem. |
| | A Reference Implementation of Ascertaining RPKI Signed Objects to be Validated in Incremental Updates |
| |
|
This document describes a reference implementation of how an RP ascertains which RPKI signed objects that need to be validated during a transaction of RPKI incremental update from the perspective of this RP. |
| | A YANG Data Model for Network Element Threat Surface Management |
| |
|
This document defines a base YANG data model for network element threat surface management that is application- and technology- agnostic. |
| | Hierarchical methods of computing metrics distribution |
| |
|
This document analyzes the necessarity of setting hierarchical methods of computing metrics distribution. Besides, we propose the workflow of hierarchical metric distribution for different CATS frameworks. |
| | SRv6 Service Benchmarking Guideline |
| |
|
This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. |
| | Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [I-D.ietf-emu-aka-pfs], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. |
| | BGP Link State Extensions for Scalable Network Resource Partition |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. |
| | Discovery of Network-designated OSCORE-based Resolvers: Problem Statement |
| |
| | draft-lenders-core-dnr-04.txt |
| | Date: |
05/02/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. |
| | Applicability of GMPLS for fine grain Optical Transport Network |
| |
|
ITU-T Recommendation ITU-T G.709/Y.1331 (2020) Amd.3 (03/2024) introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. |
| | Operations,Administration and Maintenance (OAM) for Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-oam-fw-01.txt |
| | Date: |
29/08/2024 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an OAM framework for Computing-Aware Traffic Steering (CATS). The proposed OAM framework enables the fault and the performance management of end-to-end connections from clients to networks and finally to computing instances. In the following sections, the major components of the framework, the functionalities, and the deployment considerations are elaborated in detail. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-muti-dp-solution-01.txt |
| | Date: |
29/08/2024 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios. |
| | Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
| |
|
The document [I-D.draft-mhkk-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. |
| | SAVNET Use Cases |
| |
| | draft-ys-savnet-use-cases-01.txt |
| | Date: |
13/09/2024 |
| | Authors: |
1211176911910469110103, Xueyan Song, Changwang Lin, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces the use case for Source Address Validation (SAV) applied in intra-domain and inter-domain telecommunication networks. It describes the typical routing implements and possible improvements for SAV in the use cases. |
| | 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. |
| | BGP Flowspec for Computing-Aware Traffic Steering |
| |
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework, This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. |
| | Distribute Service Metric by BGP |
| |
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| | 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 (e.g., 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. |
| | Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP |
| |
| | draft-wang-idr-bgp-nof-nlri-01.txt |
| | Date: |
14/09/2024 |
| | Authors: |
Ruixue Wang, Changwang Lin, Mengxiao Chen, Fengwei Qin, Qi Zhang, wangwenxuan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. |
| | CDNI Source Access Control Metadata |
| |
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| | CDNI Delivery Metadata |
| |
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, Open Caching request delegation behavior for Open Caching node selection, and request routing modes of traffic delegation. |
| | CDNI Private Features Metadata |
| |
|
This specification defines a mechanism for downstream content delivery networks (dCDNs) to define private extensions to the metadata model that are mutually agreed upon between participating upstream content delivery networks (uCDNs) and dCDNs. |
| | Compute-Aware Traffic Steering for Midhaul Networks |
| |
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. |
| | Light MLS |
| |
| | draft-kiefer-mls-light-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| | Working Group: |
Individual Submissions (none) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "light clients" that don't undertake these costs. A light client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a light client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| | STI Certificate Transparency |
| |
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). |
| | Self-Clocked Rate Adaptation for Multimedia |
| |
|
This memo describes a congestion control algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and is a hybrid loss- and delay based congestion control that also supports ECN and L4S. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a mobile system simulator using LongTerm Evolution (LTE) and 5G and is shown to achieve both low latency and high video throughput in these scenarios. This specification obsoletes RFC 8298. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. |
| | Private Inexpensive Norm Enforcement (PINE) VDAF |
| |
|
This document describes PINE, a Verifiable Distributed Aggregation Function (VDAF) for secure aggregation of high-dimensional, real- valued vectors with bounded L2-norm. PINE is intended to facilitate private and robust federated machine learning. |
| | End-to-End Secure Objects for Media over QUIC Transport |
| |
|
This document describes an end-to-end authenticated encryption scheme for application objects intended to be delivered over Media over QUIC Transport (MOQT). We reuse the SFrame scheme for authenticated encryption of media objects, while suppressing data that would be redundant between SFrame and MOQT, for an efficient on-the-wire representation. |
| | EVPN Group Policy |
| |
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. |
| | 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS |
| |
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. |
| | SRv6 SFC Architecture with SR-aware Functions |
| |
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, so that reduces nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://https/github.com/watal. |
| | Including Additional Records for DNSSD in DNS Push Subscriptions |
| |
|
This document extends DNS Push Notifications by providing ways for DNS Push subscribers to track additional data as well as direct answers to DNS questions. This is analogous to the support for additional data specified for multicast DNS, for example. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement. |
| | Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members |
| |
|
In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) [IEEE802.1AX]) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE, it is essential to know the connectivity relationships among bundle members. This document describes how OSPF and IS-IS would advertise the remote interface identifiers for Layer 2 bundle members. The corresponding extension of BGP-LS is also specified. |
| | PQ/T Hybrid KEM: HPKE with JOSE/COSE |
| |
|
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. |
| | Filtering Out RPKI Data by Type based on Enhanced SLURM Filters |
| |
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. |
| | SRv6 Deployment and Operation Problem Summary |
| |
| | draft-liu-srv6ops-problem-summary-04.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Yisong Liu, Dan Voyer, Thomas Graf, Zoltan Miklos, Luis Contreras, Nicolai Leymann, Linjian Song, Satoru Matsushima, Chongfeng Xie, Xinxin Yi |
| | Working Group: |
Individual Submissions (none) |
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. |
| | Securing hybrid network - criteria and requirements |
| |
|
This document analyzes requirements for ensuring and monitoring the security status of the network used under complex network environment such as hybrid cloud or mixed cloud settings. |
| | Ways to convey the Ratchet Tree in Messaging Layer Security |
| |
|
The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Multiple Hop Unaffiliate BFD |
| |
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. |
| | GMA Traffic Splitting Control |
| |
| | draft-zhu-gma-tsc-03.txt |
| | Date: |
05/09/2024 |
| | Authors: |
Jing Zhu, Menglei Zhang, Sumit Roy |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the GMA (Generic Multi-Access) traffic splitting control algorithm. The receiving endpoint measures one- way-delay, round-trip time, and delivery rate for multiple connections and determines how a data flow is split across them. When update is needed, it will send out a control message, aka Traffic Splitting Update (TSU), to notify the transmitting endpoint of the new traffic splitting configuration. Compared to other sender-based multi-path transport protocols, e.g. MPTCP, MPQUIC, the GMA traffic splitting algorithm is receiver-based and does not require per-packet feedback, e.g. Ack. It is designed specifically to support the Generic Multi-Access (GMA) convergence protocol as introduced in [MAMS] [GMA]. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. |
| | Registry policies "... with Expert Review" |
| |
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. |
| | MIMI Metadata Minimalization (MIMIMI) |
| |
|
This document describes a proposal to run the MIMI protocol in a way that reduces the ability of the Hub and service providers to associate messaging activity of clients with their respective identities. For now, this document only contains a high-level description of the mechanisms involved. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | SRv6 Resource Programming with NRP flavor |
| |
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | RDAP Extension for DNS DELEG |
| |
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. |
| | Double Nonce Derive Key AES-GCM (DNDK-GCM) |
| |
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM). It operates with a 32- byte root key and is designed to encrypt with a 24-byte random nonce (IV), and to provide for key commitment. Encryption takes the root key and a random nonce (IV), derives a fresh encryption key and a key commitment value, invokes AES-GCM with the derived key and a 12-byte zero nonce, and outputs the ciphertext, authentication tag and the key commitment value. Although this is not the primary targeted usage, it is also possible, under some restrictions, to use DNDK-GCM with a non-repeating but non-random nonce The low collision probability in a collection of 24-byte random nonces, together with the per-nonce derivation of an encryption key, extend the lifetime of the root key, and the scheme can support processing up to 2^64 bytes under a given root key. DNDK-GCM introduces relatively small overhead compared to using AES- GCM directly, and its security relies only on the standard assumption that AES acts as a pseudorandom permutation |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS procedures. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM |
| |
|
RFC 9370 specifies a framework that supports mulitple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additiona KEMs employed with the oringal ECDH to derive the final shared secret keys for IPsec protocols. The primitive goal is to mitigate the security threat against quantum computers by hybriding additional post-quantum (PQ) KEMs with the orinigal ECDH key exchange. This draft specifies how one QP KEMs, FrodoKEM, is instantiated in the IKEv2 as the additional KEMs with the main ECDH to achieve hybrid key agreement. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.D24]. ] |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | Fast Congestion Notification Packet (CNP) in RoCEv2 Networks |
| |
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. |
| | 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. |
| | A Formalization of Symbolic Expressions |
| |
|
The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. |
| | Problem Statement for Digitized Emblems |
| |
|
International law defines a number of emblems, such as the blue helmets of United Nations peacekeeping forces, the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross, as indicative of special protections under the Geneva Conventions. Similar protections attach to journalists who wear "Press" protective emblems on the battlefield, under Article 79 of Protocol I of the Geneva Conventions and Resolution 2222 of the United Nations Security Council. The emblems of national governments and inter-governmental organizations protect diplomatic pouches, couriers, and envoys under the Vienna Convention on Diplomatic Relations. Other marks enjoy protections against mis-use under the Paris Convention, the Madrid Protocol, and the Trade-Related Aspects of Intellectual Property Rights. Such physical emblems have a number of weaknesses and do not translate to the digital realm. This document provides a summary of the problems and documents identified requirements from a number of stakeholders for a digital emblem which addresses the shortcomings of the physical emblems and makes possible the indication of protections of digital assets under international law. |
| | BGP Flow Specification Version 2 - More IP Filters |
| |
|
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 defines the format for the Extended IP Filters for Flow Specification FSv2. |
| | Knowledge Graphs for YANG-based Network Management |
| |
|
The success of the YANG language and YANG-based protocols for managing the network has unlocked new opportunities in network analytics. However, the wide heterogeneity of YANG models hinders the consumption and analysis of network data. Besides, data encoding formats and transport protocols will differ depending on the network management protocol supported by the network device. These challenges call for new data management paradigms that facilitate the discovery, understanding, integration and access to silos of heterogenous YANG data, abstracting from the complexities of the network devices. This document introduces the knowledge graph paradigm as a solution to this data management problem, with focus on YANG-based network management. The document provides background on related topics such as ontologies and graph standards, and shares guidelines for implementing knowledge graphs from YANG data. |
| | Asset Profiles for Asset Exchange |
| |
|
A definition of asset schema and profiles is needed to provide a semantic definition of tokenized assets. The Asset schema is an abstract construct at the root hierarchy of more specific "asset profiles". Asset profiles describe the structure (type) of assets that are specific to a given domain or industry. An asset instance that is instantiated in a specific network and is exchanged via the SATP protocol has an instance-class relationship (in an ontological sense) with a given profile. Asset profiles are essential to the SATP protocol as they define the semantics of asset instances to be transferred. Gateways may negotiate asset transfers based on the nature and abilities of the assets as defined according to their profile. The current document discusses the definition of the asset schema and profile. |
| | 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 FSv2 actions in Extended Communites. This draft suggests additional IP actions for FSv2 in a BGP Community path attribute. |
| | 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". |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document outlines how post-quantum digital signatures, specifically Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA), can be employed as authentication methods within the IKEv2 protocol. It introduces ML- DSA and SLH-DSA capability to IKEv2 without necessitating any alterations to existing IKE operations. |
| | The "doi" URI Scheme |
| |
|
This I-D series was initially used to specify the "doi" URI scheme. This specification has since been replaced by [doi-uri-scheme]. |
| | Problem statements and requirements of Deterministic CATS on the Industrial Internet |
| |
|
The Industrial Internet is a new infrastructure, application mode and industrial ecology with the deep integration among the new information technology, communication technology and the industrial economy.Industrial production tasks are time-sensitive, which put forward high requirements on networks and applications, and need to meet the deterministic requirements in terms of delay, jitter, reliability, etc. Industrial deterministic service refers to a closed loop composed of communication paths and control processes in which two or more applications participate.Industrial management platforms need to unify network forwarding and computing tasks for each deterministic service. This draft illustrates use cases of traffic steering for deterministic service in terms of dynamic computing and networking resource status,together with the requirements and solutions for CATS(Computing-Aware Traffic Steering). |
| | The Distributed Symmetric Key Establishment (DSKE) Protocol |
| |
| | draft-mwag-dske-01.txt |
| | Date: |
10/11/2024 |
| | Authors: |
Mattia Montagna, Manfred von Willich, Melchior Aelmans, Gert Grammel |
| | Working Group: |
Individual Submissions (none) |
|
The Distributed Symmetric Key Establishment (DSKE) protocol introduces an approach to symmetric key distribution that enables robust, scalable, and future-proofed security without reliance on asymmetric encryption. This document delineates the protocol's specifications, security model, and architectural integration. Note This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. |
| | SATP Setup Stage |
| |
|
SATP Core defines an unidirectional transfer of assets in three stages, namely the Transfer Initiation stage (Stage-1), the Lock- Assertion stage (Stage-2) and the Commitment Establishment stage (Stage-3). This document defines the Setup Phase, often called "Stage-0", prior to the execution of SATP Core. During Setup, the two Gateways that would participate in the asset transfer are bound together via a "transfer context". The transfer context conveys information regarding the assets to be exchanged. Gateway can perform any kind of negotiation based on that transfer context, before entering into SATP Core. |
| | IPv6 Addresses for Ad Hoc Networks |
| |
|
Ad Hoc networks often present a challenging environment for IPv6 addressing due to the undetermined neighborhood properties of their interfaces. IPv6 nodes assign IPv6 addresses to their Ad Hoc networks that must be locally unique. IPv6 nodes must therefore be able to assign topology-independent addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type that a node can autonomously assign for each of its Ad- Hoc networks. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [I-D.ietf-emu-aka-pfs], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). |
| | 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, and some potential directions of enhancing ASPA are provided. |
| | Efficient RDAP Referrals |
| |
|
This document describes how RDAP servers can provide HTTP "Link" header fields in RDAP responses to allow RDAP clients to efficiently determine the URL of related RDAP records for a resource. |
| | Naming the Protocol specified RFC 8029 |
| |
|
RFC 8029 specifies the key MPLS Operation, Administration, and Maintenance protocol, sometimes referred to MPLS Label Switched Path (LSP) Ping, or MPLS LSP Ping. Howerver, the actual name of the protocol have never been explicitly specified or documented. This document corrects that omission. This document updates RFC 8029. |
| | Operations,Administration and Maintenance (OAM) data collection for service decision-making in Computing-Aware Traffic Steering |
| |
|
This document describes the collection of OAM data for services decision-making in Computing-Aware Traffic Steering.In the following section, the main functional components and processes of OAM data collection will be elaborated in detail. |
| | Media over QUIC - Transfork |
| |
|
MoqTransfork is designed to serve live tracks over a CDN to viewers with varying latency and quality targets: the entire spectrum between real-time and VOD. MoqTransfork itself is a media agnostic transport, allowing relays and CDNs to forward the most important content under degraded networks without knowledge of codecs, containers, or even if the content is fully encrypted. Higher level protocols specify how to use MoqTransfork to encode and deliver video, audio, messages, or any form of live content. |
| | Route Origin Registry Problem Statement |
| |
|
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin ASes (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry. |
| | YANG Data Model for SR Policy Group |
| |
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. |
| | Multicast Source Discovery Protocol (MSDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and the SendHoldTimer_Expires event in the MSDP protocol. The implementation of SendHoldTimer helps to address the situation where the local system detects that the remote system has not processed MSDP messages but has not terminated the MSDP session. According to this document, when the SendHoldTimer expires, the local system should close the MSDP session connection, rather than relying on the remote system to initiate the session closure. This document updates RFC3618. |
| | Label Distribution Protocol (LDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires event in the LDP protocol. The implementation of SendHoldTimer helps address situations where the local system detects that the remote system has not processed LDP messages but has not terminated the LDP session. The document specifies that when the SendHoldTimer expires, the local system should close the LDP session connection, rather than solely relying on the remote system for session termination. This document updates RFC5036. |
| | Path Computation Element (PCE) Communication Protocol (PCEP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires events in the PCEP protocol. The implementation of SendHoldTimer helps address situations where a local system detects that a remote system has not terminated the PCEP session despite not processing PCEP messages. As per this document, when the SendHoldTimer expires, the local system should close the PCEP connection rather than solely relying on the remote system to terminate the session. This document provides updates to RFC5440. |
| | Stateless 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 without having to store state on the host performing the actual reverse traceroute operation. |
| | SEARCH -- a New Slow Start Algorithm for TCP and QUIC |
| |
| | draft-chung-ccwg-search-05.txt |
| | Date: |
21/01/2025 |
| | Authors: |
Jae Chung, Maryam Kachooei, Feng Li, Mark Claypool |
| | Working Group: |
Individual Submissions (none) |
|
TCP slow start is designed to ramp up to the network congestion point quickly, doubling the congestion window each round-trip time until the congestion point is reached, whereupon TCP exits the slow start phase. Unfortunately, the default Linux TCP slow start implementation -- TCP Cubic with HyStart [HYSTART] -- can cause premature exit from slow start, especially over wireless links, degrading link utilization. However, without HyStart, TCP exits slow start too late, causing unnecessary packet loss. To improve TCP slow start performance, this document proposes using the Slow start Exit At Right CHokepoint (SEARCH) algorithm [KCL24] where the TCP sender determines the congestion point based on acknowledged deliveries -- specifically, the sender computes the delivered bytes compared to the expected delivered bytes, smoothed to account for link latency variation and normalized to accommodate link capacities, and exits slow start if the delivered bytes are lower than expected. We implemented SEARCH as a Linux kernel v5.16 module and evaluated it over WiFi, 4G/LTE, and low earth orbit (LEO) and geosynchronous (GEO) satellite links. Analysis of the results show that the SEARCH reliably exits from slow start after the congestion point is reached but before inducing packet loss. |
| | Requirements for Host-to-Network Collaboration Signaling |
| |
| | draft-kwbdgrr-tsvwg-net-collab-rqmts-04.txt |
| | Date: |
14/10/2024 |
| | Authors: |
John Kaippallimalil, Dan Wing, Sri Gundavelli, Sridharan Rajagopalan, Spencer Dawkins, Mohamed Boucadair |
| | Working Group: |
Individual Submissions (none) |
|
Collaborative signaling from host-to-network (i.e., client-to-network and server-to-network) can improve the user experience by informing the network about the nature and relative importance of packets (frames, streams, etc.) without having to disclose the content of the packets. Moreover, the collaborative signaling may be enabled so that clients and servers are aware of the network's treatment of incoming packets. Also, client-to-network collaboration can be put in place without revealing the identity of the remote servers. This collaboration allows for differentiated services at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission), or through cooperation of server/client and the network. This document lists some use cases that illustrate the need for a mechanism to share metadata and outlines host-to-network requirements. The document focuses on signaling information about a UDP transport flow (UDP 4-tuple). |
| | Architectural Considerations for Environmental Sustainability |
| |
|
This document describes several of the design tradeoffs for trying to optimize for sustainability along with the other common networking metrics such as performance and availability. |
| | Sustainability Considerations for Networking Protocols and Applications |
| |
|
Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementors sustainability- related advice and guideance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. |
| | 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 Credential Verifier along with the corresponding Digital Credentials. The approach outlined in this document makes the Credential Verifier able to check the status, such as the non-revocation, of a Digital Credential without requiring to query any third-party entities. |
| | IGP-based Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) |
| |
|
This document proposes a new IGP-based intra-domain source address validation (SAV) solution, called IGP-SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows intra- domain routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra-domain routing protocol. By using SAV-specific information, intra-domain routers can generate and update accurate SAV rules in an automatic way. |
| | 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. |
| | Bgp Extension for Tunnel Egress Point |
| |
|
In AI networks, flow characteristics often exhibit a low number of flows but with high bandwidth per flow, making it easy to cause network congestion when using traditional flow-level load balancing methods. Currently, the direction of traffic scheduling focuses on load sharing individual packets of the same flow, which requires sorting based on the Tunnel Egress Point information from the remote end. This document describes the method of publishing Tunnel Egress Point through the BGP protocol. |
| | 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. |
| | 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. |
| | Deterministic Networking SRv6 Data Plane |
| |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and optionaly the 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. |
| | 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. |
| | 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. |
| | 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. |
| | Data Modelling and Gap Analysis 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 side, 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 IETF models and potentially complementing that with input from other standard or industrial forum models (ITU-T, OpenConfig , ONF TAPI etc.) , this model offers enhanced uniform structuring and naming. This draft introduces the concept of "Coherent Pluggable Manifest", where it represents the capabilities of pluggable, maintained in a repository. This document also covers gap analysis of current IETF drafts and other SDOs on coherent Pluggable attributes and provides the complete lifecycle of a coherent pluggable from operators' approval through viability assessment to deployment. This document also covers an analysis of the gap between current IETF drafts and the corresponding works in other standards bodies and industry. The lifecycle of a coherent pluggable from operators' approval, viability assessment to deployment and monitoring is also covered. |
| | On-Path Telemetry for Active Performance Measurements |
| |
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | 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. |
| | VESPER PASSporT and Identity Tokens - VErifiable STI Personas |
| |
|
This document extends the STIR architecture by defining a Personal Assertion Token (PASSporT) with a type of "vesper" (VErifiable Sti PERsona) and specifies the use of PASSporTs as a JSON Web Tokens (JWT) and Selective Disclosure JWT (SD-JWT) for representing verifiable claims related to a persona (a person or business entity) associated with a Secure Telephone Identity (STI). This set of extensible claims can include verifiable information such as the assignment of a telephone number, the output of a Know Your Customer (KYC) or Know Your Business (KYB) type of vetting process, Rich Call Data (RCD) or claims of consent provided to the telephone number holder. The architecture, dependencies, and process flow of Vesper includes logical roles that represent certain responsibilities for establishing a secure telephone identity. These roles represent the basis for trusted relationships to information that is being claimed and who is validating and taking responsibility for the accuracy of that information. These roles begin with a Subject Entity (SE) that is the end entity that intended to be represented by the STI telephone number identifier. A Vetting Claim Agent (VCA) establishes the Subject Entity as a vetted entity after performing the initial vetting and existence as a entity that fulfills the criteria and policies of the ecosystem to be associated with an STI. A Notary Agent (NA) is a neutral role that maintains a graph of relationships among all roles, claims, and identities, but importantly, for protecting privacy, doesn't hold any claim information other than the recording of claim events to the STI telephone number. The NA records these claim event transactions with a corresponding transparency log that generates verifiable receipts to "notarize" the recording of these relationships and claims being established. Privacy is enabled in this Notary role because the submitters have the option of submitting hashes of claims to protect information, or may usefully want to publicly declare their association to a claim to allow the public monitoring to avoid duplicate, mistaken or negligent claims which can be identified before illegitimate usage in the eco- system can occur. Other Claim Agents are defined producing claims in the form of SD-JWT + receipts from the NA. There are multiple claim agent types with corresponding extensible claim definitions with key value pairs that can be required or optionally included. These SD- JWT + receipt claim objects are then collected by the SE into a digital wallet that it can then use for selective disclosure presentation and incorporate into a "vesper" PASSporT signed by the a delegate certificate associated with STI telephone number to validate the SE is indeed the authorized holder of the telephone number and vesper token at the time the presentation is required and ties the SE to the STIR eco-system a STIR certificates policy for use in communications. |
| | 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. |
| | Hosting Encrypted DNS Forwarders on CPEs |
| |
|
Typical connectivity service offerings based upon on Customer Premise Equipment (CPEs) involve DNS forwarders on the CPE for various reasons (offer local services, control the scope/content of information in DNS, ensure better dependability for local service, provide control to users, etc.). Upgrading DNS to use encrypted transports introduces deployment complications as to how to sustain current offerings with local services. Solutions are needed to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. This document describes the problem and to what extent existing solutions can or can't be used for these deployments. For example, Star certificates and name constraints extension suffer from the problem of deploying a new feature to CAs, TLS clients, and servers. |
| | 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. |
| | 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. |
| | YANG Data Model for IPv6 Neighbor Discovery |
| |
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), SEcure Neighbor Discovery (SEND), and Secure ND Proxy. |
| | TLS Trust Anchor Identifiers |
| |
|
This document defines the TLS Trust Anchors extension, a mechanism for relying parties 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. |
| | 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. |
| | BMPS: Transport Layer Security for BGP Monitoring Protocol |
| |
|
The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates [RFC7854] regarding BMP session establishment and termination. |
| | FC-BGP Protocol Specification |
| |
|
This document defines an extension, Forwarding Commitment BGP (FC- BGP), to the Border Gateway Protocol (BGP). FC-BGP provides security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. Forwarding Commitment (FC) is a cryptographically signed segment to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in the BGP UPDATE message. The extension is backward compatible, which means a router that supports the extension can interoperate with a router that doesn't support the extension. |
| | Web Proxy Auto Discovery Next Generation |
| |
|
This specification aims to modernize Web Proxy Automatic Discovery ([WPAD]) which was defined in 1997. At that time, the World Wide Web was much earlier in its evolution. This specification provides more modern discovery mechanisms and incorporates [PVD] Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/joshco/wpadng. |
| | IGP Reverse Metric Algorithm |
| |
|
IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. |
| | IETF Experiments |
| |
|
This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. |
| | OAuth Client ID Metadata Document |
| |
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. |
| | Intra-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Secure Nameserver Selection Algorithm for DNS Resolvers |
| |
|
Nameserver selection algorithms employed by DNS resolvers are not currently standardized in the DNS protocol, and this has lead to variation in the methods being used by implementations in the field. Recent research has shown that some of these implementations suffer from security vulnerabilities. This document provides an in-depth analysis of nameserver selection utilized by mainstream DNS software and summarizes uncovered vulnerabilities. It then provides recommendations for defending against these security and availability risks. Designers and operators of recursive resolvers can adopt these recommendations to improve the security and stability of the DNS. |
| | Signaling SAVNET Capability Using IGP |
| |
|
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. |
| | Current Options for Securing Global Routing |
| |
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. |
| | Currently Used Terminology in Global Routing Operations |
| |
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. |
| | Handling Multiple Verifiers in the RATS Architecture |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and generates Attestation Results needed by Relying Parties. This document provides a solution to inconsistent behaviors of the Verifier in the RATS architecture by introducing a mechanism to aggregate Attestation Results collected from multiple Verifiers at the Relying Party while simplifying its policy and operation. |
| | Attester Groups for Remote Attestation |
| |
|
This document proposes an extension to the Remote Attestation Procedures architecture as defined in [RFC9334] by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. |
| | Extensible Authentication Protocol (EAP) Using Privacy Pass Token |
| |
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. |
| | Captive Portal API State Structure Enhancement |
| |
|
This document specifies a new key in Captive Portal API State data structure. The purpose of the new key is to allow clients to perform the client authentication without user interaction. |
| | Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 |
| |
|
This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". |
| | Adaptive Routing Framework |
| |
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. |
| | Advertising Router Information |
| |
|
This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. |
| | Lightweight GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the UDP-based Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP), which is designed to be a lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. LW-GRASP can work reliably over UDP, making it suitable for the IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential way to adapt the LW-GRASP to work on the network without IP connectivity. |
| | Adaptive Routing Notification for Load-balancing |
| |
|
This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered into the network. |
| | Optional IS-IS Fragment Timestamping |
| |
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. |
| | Adaptive Unicast to Multicast Forwarding |
| |
| | draft-liu-mboned-adaptive-utom-01.txt |
| | Date: |
18/10/2024 |
| | Authors: |
Yisong Liu, Aijun Wang, Changwang Lin, Zheng Zhang, Yuanxiang Qiu, Yanrong Liang |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an adaptive optimization method of unicast forwarding for network devices to solve the problem that unicast service traffic takes up too much bandwidth of the IP carrier network under the point to multipoint scenarios. |
| | Fully Adaptive Routing Ethernet using BGP |
| |
| | draft-xu-idr-fare-02.txt |
| | Date: |
01/09/2024 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Tiezheng |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource- intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three- stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute the traffic to the same destination over multiple equal-cost paths, based on the network capacity and even congestion information along those paths. |
| | OAM Requirements for Enhanced DetNet OAM |
| |
|
This document describes the specific requirements of the Operations, Administration, and Maintenance (OAM) for Enhanced DetNet, and analyzes the gaps with the existing OAM methods. It describes related OAM solutions considerations as well. |
| | Root CA Certificate Rekeying in the Scenario of Post Quantum Migration |
| |
|
In the public key infrastructures (PKIs), root certifcation authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a one-way link certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the cerficate can be pure PQ ones or hybrid ones. |
| | SPICE GLUE: GLobal Unique Enterprise Identifiers |
| |
|
This specification defines the glue URI scheme and the rules for encoding these URIs. It also establishes the registries necessary for management of this scheme. |
| | User Discovery Requirements |
| |
|
This document defines requirements for the user discovery problem within the More Instant Messaging Interoperability (MIMI) working group. User discovery is essential for interoperability, allowing message senders to locate recipients across diverse platforms using globally unique, cross-service identifiers (e.g., email addresses, phone numbers). The core challenge involves reliably mapping these identifiers to messaging service providers and determining the reachability of a recipient's identifier across multiple providers. |
| | Outer Header Translator - multihoming |
| |
|
This document describes how to achieve multihoming using OHT. This document describes both the use of provider addresses and provider independent addresses. |
| | Pacing in Transport Protocols |
| |
| | draft-welzl-iccrg-pacing-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | Extensible Delegation for DNS |
| |
| | draft-wesplaap-deleg-02.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
Individual Submissions (none) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | Track Switching in Media over QUIC Transport |
| |
|
This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other. |
| | A Safe Application Interface to Messaging Layer Security |
| |
|
The Messaging Layer Security protocol enables a group of participants to negotiate a common cryptographic state. While the primary function of MLS is to establish shared secret state for the group, an MLS group also captures authentication information for group participants and information on which the group has confirmed agreement. This document defines an interface interface by which multiple uncoordinated application functions may safely reuse the cryptographic state of an MLS group for application purposes. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Multi-path |
| |
|
STAMP is typically used to perform the measurement of one-way and round-trip performance metrics. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends STAM with a Multi-path TLV to implement the multi-path performance measurement, which can help the operators to know the performance of network comprehensively and efficiently. |
| | A Profile for Signed Group of Multiple-Origin Autonomous Systems for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document defines a "Signed MOAS Group", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to authenticate the collective announcement of IP prefixes by Multiple Origin Autonomous System (MOAS). The Signed MOAS Group mainly includes two parts: an IP prefix and a list of Autonomous Systems (ASes) authorized to announce the prefix. At least one of these ASes SHOULD be authorized to announce the prefix by the prefix owner through a Route Origin Authorization (ROA). The validation of a Signed MOAS Group confirms that the authorized ASes and other listed ASes have collectively agreed to announce the prefix, ensuring that the announcement is legitimate, accurate, and mutually authorized. |
| | YANG Data Models for fine grain Optical Transport Network |
| |
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1G client signals in transport network. |
| | A YANG Data Model for Resource Performance Monitoring |
| |
| | draft-yu-ccamp-resource-pm-yang-01.txt |
| | Date: |
03/01/2025 |
| | Authors: |
Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, Mingshuang Jin |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. |
| | A YANG Data Model for Service Path Computation |
| |
|
This document defines a YANG data model for client signal service's path computation and path management. |
| | Upper limit values for DNS |
| |
|
There are parameters in the DNS protocol that do not have clear upper limit values. If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks, and several attack methods have been proposed. This draft proposes reasonable upper limit values for DNS protocols. |
| | Advertising Network Resource Partition (NRP) Policy in BGP |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and the associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services or RFC 9543 network slice services. For the instantiation of an NRP, NRP- specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy. This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality. |
| | Source Prefix Advertisement for Intra-domain SAVNET |
| |
|
This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. SPA- based SAVNET allows routers in an intra-domain network to exchange SAV-specific information through SPA messages. Compared with existing intra-domain SAV mechanisms RFC2827 [RFC3704], SPA-based SAVNET can generate more accurate and robust SAV rules on intra- domain routers in an automatic way. This document introduces the content of SPA messages and the process of generating SAV rules. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document. |
| | IGP Reverse Prefix Metric |
| |
|
This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. |
| | Semi-Private Messages in the Messaging Layer Security (MLS) Protocol |
| |
|
This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. |
| | PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters |
| |
|
This document defines PQ/T composite schemes based on ML-KEM and ML- DSA combined with ECC algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol. |
| | Benchmarking Methodology for Source Address Validation |
| |
|
This document defines methodologies for benchmarking the performance of source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations. |
| | A Framework and Definition for Collective Communication Offloading |
| |
|
This document provides a definition of the term "Collective Communication Offloading" for use within the IETF and specifically as a reference for other IETF documents that describe or use aspects of Collective Communication Offloading. The document also describes the characteristics of an IETF Collective Communication Offloading, related terms and their meanings, and discusses the general framework for Collective Communication Offloading, the necessary system components and interfaces. |
| | Deep Collaboration between Application and Network |
| |
|
This document analyzes the necessarity of deep collaboration between the application and network. Besides, the problem, usecase and requirement of bidirectional awareness between the application and network are discussed. |
| | Integration of DNS Domain Names into Application Environments: Motivations and Considerations |
| |
|
This document reviews the motivations and considerations for integrating DNS domain names into an application environment and provides terminology to establish a shared understanding of what a DNS integration may entail. |
| | Network Attestation for Secure Routing (NASR) Architecture |
| |
|
This document provides an architecture overview of NASR entities, interactive procedures and messages. |
| | Source Address Validation Enhanced by Network Controller |
| |
|
Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. |
| | WIMSE Token Exchange and Translation Protocol |
| |
|
The specification defines the processes of token exchange and token translation for workloads. Token exchange is introduced in [RFC8693], allowing the exchange of access tokens, OpenID Connect ID Tokens, and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by [RFC8693]. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Kerberos service tickets, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT OAuth 2.0 Acesss Tokens [RFC9068], CWT [RFC8392], and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in [RFC8693], and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in (todo: add link to use cases doc). |
| | HTTP Resource Versioning |
| |
|
HTTP resources change over time. Each change to a resource creates a new "version" of its state. HTTP systems often need a way to identify, read, write, navigate, and/or merge these versions, in order to implement cache consistency, create history archives, settle race conditions, request incremental updates to resources, interpret incremental updates to versions, or implement distributed collaborative editing algorithms. This document analyzes existing methods of versioning in HTTP, highlights limitations, and sketches a more general versioning approach that can enable new use-cases for HTTP. An upgrade path for legacy intermediaries is provided. |
| | The Correspondence between Packets and SRv6 Tunnels |
| |
|
This paper introduces a new extension header, the SRv6 Policy Key, which addresses the issues of timeliness and accuracy in controller- aware path management within SRv6 networks. By adding a unique path identifier to the message header, this scheme enables network nodes to report path information to the controller. This ensures that the controller maintains a real-time and accurate view of the SR path status, even if the SID is lost during transmission or if the controller cannot monitor it in real time and accurately. The approach aims to enhance network availability and operational efficiency, particularly in scenarios involving multi-path tunnel configurations and load balancing. |
| | Incrementally Deployable Extensible Delegation for DNS |
| |
|
This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with resource record sets placed below a _deleg label in the apex of the delegating zone. This authoritative delegation point can be aliased to other names using CNAME and DNAME. This document proposes a new DNS resource record type, DELEG, which is based on the SVCB and inherits extensibility from it. Support in recursive resolvers suffices for the mechanism to be fully functional. The number of subsequent interactions between the recursive resolver and the authoritative name servers is comparable with those for DNS Query Name Minimisation. Additionally, but not required, support in the authoritative name servers enables optimized behavior with reduced (simultaneous) queries. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed. |
| | Ethernet VPN (EVPN) Multicast Leave Synch Route Update |
| |
|
The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) specification describes the procedures to synchronize IGMP/MLD membership report and leave group states in all the PEs that are attached to the same Ethernet Segment. In particular, the Multicast Leave Synch route described in the same specification, synchronizes the leave procedures on all the members of the Ethernet Segment, for a multicast group and for an amount of time (the Maximum Response Time). The use of the Maximum Response Time may be different depending on whether the local state was created by IGMPv2, IGMPv3 or MLDv2. In addition, the Maximum Response Time advertised in the Multicast Leave Synch route needs to account for the time that it takes for the route to be propagated in the network, which might not be easy to predict. This document clarifies the use of the Maximum Response Time and updates the procedures for the Multicast Leave Synch route. |
| | Encryption Key Derivation in the COSE using HKDF with SHA-256 |
| |
|
This document specifies the derivation of the content-encryption key in CBOR Object Signing and Encryption (COSE). This mechanism protects against attacks where an attacker manipulates the content- encryption algorithm identifier. |
| | SLAAC Prefixes with Variable Interface ID (IID) Problem Statement |
| |
|
In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. |
| | SLAAC Prefixes with Variable Interface ID (IID) |
| |
|
This draft proposes the use of a longer prefixes in PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits. This would eliminate the race to the bottom concerns. This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. |
| | Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile |
| |
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for applications that use Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Mobile Traffic Steering |
| |
| | draft-liebsch-dmm-mts-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Individual Submissions (none) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | SRv6 Inter Domain Routing |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | On Numbers in CBOR |
| |
|
The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers and implementers of CBOR libraries and of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is a rather drafty initial revision, pieced together from // various components, so it has a higher level of redundancy than // ultimately desired. |
| | Applicability of Computing-Aware Traffic Steering to Intelligent Transportation Systems |
| |
|
This document describes the applicability of Computing-Aware Traffic Steering (CATS) to Intelligent Transportation Systems (ITS). CATS provides the steering of packets of a traffic flow for a specific service request toward the corresponding service instance at an edge computing server at a service site. CATS are applicable for Computing-Aware ITS including (i) Context-Aware Navigation Protocol (CNP) for Terrestrial Vehicles and Unmanned Aerial Vehicles (UAV), (ii) Edge-Assisted Cluster-Based MAC Protocol (ECMAC) for Software- Defined Vehicles, and (iii) Self-Adaptive Interactive Navigation Tool (SAINT) for Cloud-Based Navigation Services, and (iv) Cloud-Based Drone Navigation (CBDN) for Efficient Drone Battery Charging. |
| | OpenID Connect standard claims registration for CBOR Web Tokens |
| |
|
This document registers OpenId Connect standards claims already used in JSON Web Tokens for CBOR Web Tokens. |
| | Deterministic Networking specific MNA |
| |
|
In IETF, the Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. This document focuses on the MPLS Data Plane, namely, how to use MNA (MPLS Network Action) for DetNet flows, when forwarded over an MPLS technology-based network domain. |
| | Framework for efficient Service Carving in EVPN Multihoming |
| |
|
This document proposes a new approach for the Designated Forwarder (DF) selection algorithm. This is besides the existing algorithm types discussed in RFC7432 and RFC8584. A DF is a PE part of an Ethernet-Segment, forwarding BUM traffic to multi-homed hosts. This document discusses methods to achieve efficient service carving in Evpn Multi-homed networks by extending the DF selection algorithm type in RFC7432 by suggesting a new approach for service carving. |
| | Interface to In-Network Functions (I2INF): Problem Statement |
| |
|
This document specifies the problem statement for the Interface to In-Network Functions (I2INF) for user services both on the network- level and application-level. In-Network Functions (INF) include In- Network Computing Functions (INCF) which are defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). INF also includes In-Network Application Functions (INAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of INFs in a target network. This document investigates the need for a standard framework with the interfaces for INFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor INFs. |
| | A Framework for the Interface to In-Network Functions (I2INF) |
| |
|
This document specifies a framework to define Interface to In-Network Functions (I2INF) for user services both on the network-level and application-level. In-Network Functions (INF) include In-Network Computing Functions (INCF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). INF also includes In-Network Application Functions (INAF) which appear in the context of Internet-of-Things (IoT) Devices, Software- Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2INF framework, which includes components and interfaces to configure and monitor the INFs that implement applications and services. |
| | EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission |
| |
| | draft-xls-intarea-evn6-03.txt |
| | Date: |
21/02/2025 |
| | Authors: |
Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| | Conceptual Model for Digitized Emblems |
| |
|
This document describes the conceptual models of use for digital emblems. |
| | ASPA-based AS_PATH Verification for BGP Export |
| |
|
This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers. |
| | EVPN Route Types and Procedures for EVN6 |
| |
|
EVN6 is a mechanism designed to carry Ethernet virtual networks, providing Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 directly places the Ethernet frames in the payload of IPv6 packet, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. |
| | An Interplanetary DNS Model |
| |
|
As human activity continues to spread beyond the Earth, so must the communications systems which support that activity continue to expand in scope. One such case, Internet naming, presents particular challenges when considering a multi-planet civilization. Proper operation of terrestrial DNS services and clients require constant, reasonably low latency connectivity to operate properly. These conditions are distinctly not present when considering interplanetary links; high latency and frequent disruption due to space weather events and general link availability prevail. To overcome these challenges in space networking, a delay and distruption tolerant (DTN) suite of protocols has been developed based on a store and forward mechanism, Bundle Protocol(BP). This DTN network, which optimizes to ensure bundle delivery, does not allow for end to end encapsulation of IP packets beyond terrestrial boundaries, as the latency still creates issues completing network transactions, even in the unlikely event of continuous link availability. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document describes a potential protocol extension involving the addition of four new attributes to be used by servers to provide support for POSIX ACLs. The term POSIX ACLs refers to the ACL component of the Portable Operating System Interface (POSIX) 1003.1e draft 17 [IEEE] document for which sponsorship was withdrawn in January 1998. Although the draft POSIX standard that describes these ACLs was never ratified, several POSIX-based operating systems, such as Linux, Solaris and FreeBSD include support for them. The NFS Version 4 (NFSv4) ACLs described in [RFC8881] henceforth referred to as NFSv4 ACLs, use a different model and attempts to map between the ACLs of these two models have not been completely successful. In order to adequately support POSIX ACLs, this document proposes four new attributes that may optionally be used by an NFS Version 4, minor version 2 (NFSv4.2) server to support ACLs that conform to the aforementioned POSIX 1003.1e draft 17. |
| | Robots Exclusion Protocol Extension for URI Level Control |
| |
|
This document extends RFC9309 by specifying additional URI level controls through application level header and HTML meta tags originally developed in 1996. Additionally it moves the response header out of the experimental header space (i.e. "X-") and defines the combinability of multiple headers, which was previously not possible. |
| | A Top-level Domain for Private Use |
| |
|
This document describes the "internal" top-level domain for use in private applications. |
| | An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems |
| |
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. |
| | I2NSF Analytics Interface YANG Data Model for Closed-Loop Security Control in the I2NSF Framework |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-i2nsf-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. |
| | CoRIM profile for AMD SEV-SNP attestation report |
| |
|
AMD Secure Encrypted Virtualization with Secure Nested Pages (SEV- SNP) attestation reports comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an AMD SEV-SNP virtual machine. This document specifies the information elements for representing SEV-SNP Reference Values in CoRIM format. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/deeglaze/draft-deeglaze-amd-sev-snp-corim-profile. |
| | The Internet Standards Process |
| |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC2026, RFC6410, RFC7100, RFC7127, RFC8789, and RFC9282. It updates RFC5657. It also includes the changes from RFC7475, and with [bis2418], obsoletes it. |
| | Organization Trust Relationship Protocol |
| |
|
This document specifies the "Organization Trust Relationship Protocol" method for service owners (organizations) to express in a standard format their trusted relationships with other organizations, as well as identify the social networks they control. This method was originally defined by Scott Yates in 2020 for this purpose. |
| | IETF Working Group Guidelines and Procedures |
| |
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [bis2026], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. |
| | Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 |
| |
|
This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management on telecom and computer networks requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge graphs can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management (ITSM) Knowledge Graph (KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| | Hierarchical Deterministic Keys |
| |
|
Hierarchical Deterministic Keys enables managing large sets of keys bound to a secure cryptographic device that protects a single key. This enables the development of secure digital identity wallets providing many one-time-use public keys. Some instantiations can be implemented in such a way that the secure cryptographic device does not need to support key blinding, enabling the use of devices that already are widely deployed. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptograph (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptograph algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | Secure Key Integration Protocol (SKIP) |
| |
| | draft-cisco-skip-00.txt |
| | Date: |
30/08/2024 |
| | Authors: |
Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. |
| | Internet Relay Chat Protocol version 3 |
| |
|
This document describes version 3 of the Internet Relay Chat (IRC) protocol, which extends the original IRC protocol to include support for audio and video capabilities. It defines new message types, commands, and channel modes that allow for the transmission of audio and video data within the existing IRC framework, while maintaining backward compatibility with text-only clients and servers. |
| | A YANG Data Model for In Situ Operations,Administration,and Maintenance (IOAM) Integrity Protected Options |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. I-D.ietf-ippm- ioam-data-integrity defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the configuration of these Integirty Protected Options. |
| | Revisiting the Use of the IP Protocol Stack in Deep Space |
| |
|
This document describes aspects of communication over interplanetary distances that make the use of the Internet protocol stack in a deep space network inadvisable. |
| | Sockets API Extensions for In-kernel QUIC Implementations |
| |
|
This document describes a mapping of In-kernel QUIC Implementations into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new QUIC features, and a consolidated error and event notification scheme. In-kernel QUIC enables usage for both userspace applications and kernel consumers. |
| | BGP Extension for SRv6 Policy Segment List optimization |
| |
|
In some use cases, an SRv6 policy's segment list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This document specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. This optimization can improve the forwarding efficiency of data packets when End SID and Service SID are present. |
| | BGP SR Policy Extensions for Administrative Flags |
| |
|
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 an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | IPv6 Voucher-Based Addressing for Neighbor Discovery Address Resolution |
| |
|
Voucher-Based Addressing is an extensible IPv6 address generation and verification methodology for SLAAC-enabled local networks. Individual link-layer identifiers are bound to sets of deterministic output IP addresses. Neighbor Discovery Link Voucher options distributed with Router Advertisement or Redirect messages form a shared consensus between neighbors of the parameters used to auto- generate interface addresses. Cryptographic key derivation functions are used to generate pseudo-random addresses and to intentionally stretch address computation times. Host-selected parameters can be used to derive any number of both stable and ephemeral, privacy- focused addresses for each on-link prefix and at the link-local scope. Neighbors can then verify the link-layer-to-IP bindings during NDP address resolution processes to prevent active neighbor spoofing attacks in local networks. |
| | A method for delivery of SMTP messages over Bundle Protocol networks. |
| |
|
Delay and disruption tolerant networks are a foundational component of Interplanetary Internet communications. This document will treat several methods and modes of operation of Mail Transfer Agents in concert with Bundle Protocol Agents which allow SMTP interoperability between discrete IP networks bridged by DTNs. |
| | Stateless OSCORE |
| |
|
OSCORE (Object Security for Constrained Restful Environemnts, [RFC8613]) provides secure communication between peers that share symmetric key material. This document describes how a server can operate with an arbitrarily large number of peers, and how key material for this kind of operation can be provisioned to the client. |
| | BGP Flow Specification Extensions for Scheduling |
| |
|
BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time. This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic. |
| | SCHC Rule Format for Forward Error Correction (FEC) in Fragmentation |
| |
|
This document defines a new Rule Format for Forward Error Correction (FEC) of SCHC Fragments. It is backwards compatible with RFC8724, as an implementation which does not have the necessary FEC code implementations can simply ignore the messages with this new RuleID format. |
| | Knowledge Graph Framework for Network Operations |
| |
| | draft-mackey-nmop-kg-for-netops-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Michael Mackey, Benoit Claise, Thomas Graf, Holger Keller, Dan Voyer, Paolo Lucente |
| | Working Group: |
Individual Submissions (none) |
|
This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mike-mackey. |
| | Adding an Uncacheable Attribute to NFSv4.2 |
| |
|
The Network File System v4.2 (NFSv4.2) allows a client to cache both the metadata and the data for a file object. It can also cache the metadata for a directory object. Caching the dirents (i.e., the metadata) allows the client to avoid querying the server to refresh information. But this defeats the server checking to see if the user has permission to view the dirent's attributes. Caching the data can cause performance impacts if the page cache hit rate is low.. This document introduces a new file attribute called uncacheable which indicates that the client MUST NOT cache the metadata or data for that dirent. This document extends NFSv4.2 (see RFC7863). |
| | IS-IS Extension for Big TLV |
| |
|
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a solution to IS-IS extension for encoding the TLV whose value is bigger than 255 octets. |
| | SR Policies Extensions for Headend Behavior in BGP-LS |
| |
|
The SRv6 Policy Headend Behaviors are defined in [RFC8986]. This document defines extensions for carrying Headend Behavior when delivering SR Policies using Border Gateway Protocol Link-State (BGP-LS). |
| | BGP FlowSpec Extension for Traffic Scheduling |
| |
|
Traditional QoS technology can not achieve fine adjustment in the traffic scheduling, and has a large amount of configuration and poor maintainability. BGP FlowSpec technology provides a wealth of filtering conditions and processing actions, using BGP network layer reachable information (NLRI) to transmit traffic filtering information, which can achieve a more fine-grained control of the traffic and improve maintainability. This document defines the extension of BGP FlowSpec, adding new traffic filtering actions for extended community: minimum bandwidth guarantee and congestion management, to enable better management and scheduling of traffic, further improving the scalability and applicability of FlowSpec. |
| | VoxelVideo Format |
| |
|
This document proposes the VoxelVideo format, a file structure designed specifically for the efficient handling, playback, and livestreaming of 3D voxel-based videos. The format is intended for applications in gaming, virtual reality, live sports, and interactive media, providing a robust framework for managing complex 3D data with spatial precision and color fidelity. This document describes the current JSON-based version and outlines future plans to adopt a more efficent, compressed format. |
| | Reverso for the QUIC protocol |
| |
|
This document describes a QUIC extension re-designing the layout of the QUIC protocol to avoid memory fragmentation at the receiver and allows implementers seeking a more efficient implementation to have the option to implement contiguous zero-copy at the receiver. This document describes the change from QUIC v1 required in packet formats, variable-length integers and frame formats. Everything else from QUIC v1 described in [RFC9000] is untouched. |
| | Domain variant support for EPP |
| |
|
This document defines an EPP extension allowing clients to learn about and manipulate variant groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant. |
| | DNS to Web3 Wallet Mapping |
| |
|
This document proposes a implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security. |
| | Addition of Extended DNS Errors codes |
| |
|
This document is the specification of three new EDE (Extended DNS Errors) codes, for minimal answers, local roots and tailoring based on the client IP address. |
| | Email Retention Extensions |
| |
|
This document proposes extensions to the SMTP, IMAP, POP3, and MIME protocols to introduce a standard mechanism for email retention period management. |
| | Standard API Password Change Interface (SAPI) for Password Change Procedures |
| |
|
This document proposes a standardized set of API endpoints for securely changing user passwords, using a unique identifier prefix to ensure compatibility and avoid conflicts with other APIs. As the number of online accounts continues to grow, managing passwords has become increasingly challenging. Even with the use of password managers, the process of updating passwords-whether due to a security breach, expiration, or other reasons-remains a time-consuming and manual task. Currently, there is no standardized method for performing password changes across various platforms, which further complicates this process. The goal of this proposal is to establish a universal standard for password change processes, enabling password managers and services to automate password updates with minimal configuration, thereby reducing the burden on users and improving overall security. |
| | Identifying and Authenticating Home Servers: Requirements and Solution Analysis |
| |
| | draft-rbw-home-servers-00.txt |
| | Date: |
19/09/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Mohamed Boucadair, Dan Wing |
| | Working Group: |
Individual Submissions (none) |
|
Obtaining CA-signed certificates for servers within a home network is difficult and causes problems at scale. This document explores requirements to improve this situation and analyzes existing solutions. |
| | Title File Size Download Prompt (FSDP) |
| |
|
In the context of limited mobile data plans, it is crucial to manage data usage efficiently. This document proposes a method using the HTTP `OPTIONS` header to retrieve the size of a file before downloading. By checking the `Content-Length` header, users can be informed of the file size and prompted to confirm the download. This approach helps users avoid unexpected data consumption and ensures better control over their mobile data usage. |
| | Be Excellent To Each Other |
| |
|
The greatest and least heinous of all golden rules. |
| | Organization of IETF Process Documents |
| |
|
This document suggests that the IETF's many documents related to process and procedures need to be better organized and consolidated, and outlines a possible framework for this. |
| | CATS BGP Extension |
| |
|
CATS (Computing-Aware Traffic Steering) is a traffic engineering approach that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a service contact instance. This document defines the control plane BGP extension for CATS (Computing-Aware Traffic Steering). |
| | Stateless MNA-based Egress Protection (SMEP) |
| |
|
The MPLS Network Action (MNA) framework provides a general mechanism for the encoding and processing of network actions and their data. The MPLS Egress Protection Framework specifies a fast reroute framework for protecting IP/MPLS services. To that, end bypass tunnels have to be signaled to the Point of Local Repair (PLR). Further, the PLR must maintain the bypass forwarding state on a per- transport-tunnel basis. This document defines the encoding for the Stateless MNA-based Egress Protection (SMEP) network action. The SMEP network action protects egress routers by providing an alternative MPLS egress label in- stack. SMEP does not require a bypass forwarding state in PLRs. |
| | TOTP Secure Enrollment |
| |
|
This document describes a secure key exchange scheme that extends the Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment method to prevent compromise of the non-expiring TOTP key by photographic capture of the QR code or by intentional or unintentional persistence of the key string in email, SMS, or other systems outside of the TOTP authenticator system itself. |
| | The Lightweight Directory Access Protocol (LDAP) Subentry Name Form |
| |
|
This informational Internet-Draft (I-D) clarifies certain aspects of RFC3672, and provides commentary regarding the behavior of DIT structure rules and name forms as they relate to, and interact with, subentries present within various directory implementations. This I-D also incorporates the 'subentryNameForm' derived from ITU-T Rec. X.501. |
| | Using BMP over QUIC connection |
| |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | PCEP over QUIC |
| |
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. |
| | RTCP Messages for Point Cloud Prioritization |
| |
|
This document specifies RTCP messages and RTP header extensions for exchanging parameters of real-time streamed point clouds. A sender can notify receivers of the currently applied parameters, such as selected regions, and their parameters, such as the respective resolutions and included point attributes. A receiver can request updates to the same parameters using RTCP feedback messages. |
| | Multi-Push-Based Security Event Token (SET) Delivery Using HTTP |
| |
|
This specification defines how multiple Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS. The SETs are transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. |
| | NETCONF Transport Port Numbers |
| |
|
This document releases NETCONF-related port number IANA assignments that were made for inappropriate transport protocols or for an Historic NETCONF-related protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Configuration Working Group mailing list (netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/netconf-port-numbers. |
| | RPKI Repository Problem Statement and Analysis |
| |
|
With the widespread deployment of Route Origin Authorization (ROA) and Route Origin Validation (ROV), Resource Public Key Infrastructure (RPKI) is vital for securing inter-domain routing. RPKI uses cryptographic certificates to verify the authenticity and authorization of IP address and AS number allocations and the certificates are stored in the RPKI Repository. This document conducts the data-driven analysis of the RPKI Repository, including a survey of worldwide AS administrators and a measurement and analysis of the existing RPKI Repository. This document finds that the current RPKI Repository architecture is sensitive to failures and lacks of scalability. An attack or downtime of any repository Publication Point (PP) will prevent RPs from obtaining complete RPKI object views. Furthermore, since the current RPKI Repository is not tamper-resistant, RPKI authorities can easily manipulate RPKI objects without consent from subordinate INR holders. |
| | DRIP Entity Tag (DET) Registration using CoAP & CWTs |
| |
|
This document specifies a registration interaction model and interfaces for DRIP Entity Tags to a DRIP Identity Management Entity using the Constrained Application Protocol and CBOR Web Tokens. |
| | DRIP Entity Tag (DET) Differentiated Access using RDAP |
| |
|
This document defines an RDAP profile and extension data model for UAS registration. It also gives recommendations for AAA mechanisms. |
| | Extending YANG modules at runtime |
| |
|
This document describes a mechanism of signaling extensions to YANG modules that can be used when YANG is not used in an online fashion. |
| | Problem Statement with Aggregate Header Limit |
| |
|
This document first updates the concept "Aggregate header limit"(AHL) which is originally proposed in RFC8883 to indicate the total header size that a router is able to process at full forwarding rate. Then this document describes the problems for path calculation and function enablement without the awareness of AHL in IPv6, and the considerations for AHL collection are also included. |
| | Hybrid-Function-Chain (HFC) Framework |
| |
|
With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, a Hybrid-Function-Chain (HFC) framework is proposed in this draft, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning. |
| | Schedule for Segment Routing Policy |
| |
|
This document defines the Segment Routing (SR) Policy extension for schedule (called SR-Schedule). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR policy schedule including the SR-Schedule definition, acquisition, computation, enforcement, and the handling behaviors on the headend. |
| | Segment Routing Policy-Based Source Address Validation (SAV) Mechanism |
| |
| | draft-li-savnet-srsav-00.txt |
| | Date: |
29/09/2024 |
| | Authors: |
Xueting Li, Aijun Wang, Wei Wang, Yuanyuan Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This draft proposes a novel mechanism for Source Address Validation (SAV) message propagation based on Segment Routing policies (SR- policy). Traditional SAV mechanisms often rely on routing tables (RIB) and Policy-Based Routing (PBR), but these methods lack the flexibility and granularity needed for some network environments. By leveraging the flexibility and control capabilities of SR-policy, the proposed mechanism ensures that SAV messages are propagated along well-defined paths, ensuring efficient, secure, and accurate source address validation. |
| | PAKE Usage in TLS 1.3 |
| |
|
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as an authentication and key establishment in TLS 1.3, and that supports PAKE algorithms negotiation. |
| | A YANG Data Model for Network Element Threat Surface Management |
| |
|
This document defines a base YANG data model for network element threat surface management that is application- and technology- agnostic. |
| | Bundle Protocol Version Demultiplexing |
| |
|
Since the publication of [RFC5050] a number of transport and convergence layer protocols have been developed to carry bundles between nodes in a delay-tolerant network. Before the publication of Bundle Protocol version 7 (BPv7) in [RFC9171], there was only one standardized version of the Bundle Protocol, version 6, and as many of these transport and convergence-layer protocols pre-date the publication of version 7, they do not include any protocol mechanism to differentiate between versions of the Bundle Protocol. This document describes a mechanism by which an implementation can efficiently determine validity and the version of the Bundle Protocol that was used to encode a bundle by examining the initial octets of the encoded data, allowing this document to be used as a normative reference for updates to existing protocols. Additionally, this document updates [RFC9171] by defining a CBOR [RFC8949] tag that may be used as an explicit indicator that a particular indefinite-length CBOR array is a Bundle Protocol version 7 bundle. |
| | Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6) |
| |
|
This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment. |
| | Protocol Translation Between Industrial Field Network and Backbone Network Based on IPv6 |
| |
|
This document describes a protocol conversion framework that can achieve interconnection between various industrial field networks and backbone network based on IPv6. The described scheme can ensure the quality of service and industrial traffic characteristics for cross- network data flows. |
| | Absolute Capture Timestamp RTP header extension |
| |
|
This document describes an RTP header extension that can be used to carry information about the capture time of a video frame / audio sample, and include information that allows the capture time to be estimated by the receiver when the frame may have passed over multiple hops before reaching the receiver. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | Use of SHA-3 in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec |
| |
|
This document specifies the use of HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512, KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-224, SHA3-256, SHA3-384 and SHA3-512 are also specified. |
| | BGP Community Container Attribute |
| |
|
Route tagging plays an important role in external BGP (RFC4271) relations for communicating various routing policies between peers. It is also a common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities (original, extended or large). This document defines a new flexible Community encoding in a BGP Attribute that enhances what can be accomplished with BGP communities. Three initial use cases for this are flow specification version 2 (FSv2) actions, routing policy distribution (rpd) actions, and wide communities. |
| | Secure SMTP/TLS SRV Announcement |
| |
|
This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. |
| | DKIM Hash Algorithm Adaptivity |
| |
|
DKIM (RFC 6376, section 3.7) defines how "data-hash" is generated as input to a "sig-alg" for the purpose of generating a cryptographic signature. Different to the RSA algorithm (RFC 8017) solely defined for and by DKIM at the time of its creation, modern signature algorithms, for example EdDSA (RFC 8032), include extensive data hashing as part of the signing process. For these algorithms it may make sense not to create a "data-hash", but to use the entire data as input to "sig-alg". This specification allows DKIM signing algorithms "data-hash" adaptivity, taking advantage of algorithm design, and digital signature API reality. |
| | DKIM Signing Algorithm AdaEd25519-SHA256 |
| |
|
This specification adds the DKIM (RFC 6376) signing algorithm AdaEd25519-SHA256. It is identical to Ed25519-SHA256 (RFC 8463) except for its use of DKIM hash algorithm adaptivity. Private and public keys are identical, and can be used interchangeably. |
| | Privacy Primer for vCon Developers |
| |
|
This document serves as a primer for technical professionals involved in managing personal data, including biometric information from audio and video recordings, and other sensitive information in messaging or personal communications. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, and disclosure of consumer data. The document covers fundamental privacy principles, defines important roles in data processing, and explains consumer rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address consumer data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices. |
| | Key Expansion Based on Internet X.509 Public Key Infrastructure for Anonymous Voting |
| |
|
This document focuses on developing a key expansion method based on the internet X.509 public key infrastructure and elliptic curve cryptography, which is applied in the context of anonymous voting. The method enables end entities to maintain anonymity from other end entities, the registration authority, and the certificate authority, while still allowing the validity of end entity certificates to be verified, thereby facilitating anonymous voting services. |
| | SenML is CORECONF (almost) |
| |
|
SenML is one of the data formats used by the Internet-of-Things (IoT) devices to send simple sensor readings and device parameters over the network. However, a lack of a YANG model for SenML means it cannot be used by the applications which already use YANG for data modeling and validation. Furthermore, some of the encoding formats and tools available for YANG models, cannot be used by the devices sending data in SenML format. This document provides one of the ways to model SenML data in YANG. Additionally, SenML data is encoded into CORECONF format using this YANG model to concisely represent the data. |
| | Current State of the Art for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Networks (HP-WANs) represent a critical infrastructure for the modern global research and education community, facilitating collaboration across national and international boundaries. These networks, such as Janet, ESnet, GÉANT, Internet2, CANARIE, and others, are designed to support the general needs of the research and education users they serve but also the the transmission of vast amounts of data generated by scientific research, high-performance computing, distributed AI-training and large-scale simulations. This document provides an overview of the terminology and techniques used for existing HP-WANS. It also explores the technological advancements, operational tools, and future directions for HP-WANs, emphasising their role in enabling cutting-edge scientific research, big data analysis, AI training and massive industrial data analysis. |
| | ML-KEM Security Considerations |
| |
|
NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM - that is, what problem it solves, and how to use it securely. |
| | Discovery of Network Rate-Limit Policies (NRLPs) |
| |
| | draft-brw-scone-rate-policy-discovery-02.txt |
| | Date: |
16/12/2024 |
| | Authors: |
Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Gyan Mishra, Markus Amend, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
This document specifies an extension to the ACME protocol [RFC8555] that enables ACME servers to use the public key authentication protocol to verify that the client has control of the private key corresponding to the public key. This document also defines several application methods for binding identity information to public keys. |
| | Computing-Aware 5G Edge Enhancement |
| |
|
This draft illustrates a computing-aware use case that is based on the study conclusion of the 3GPP 5G enhanced Edge Computing (eEdge). This use case takes into acount both network and computing metrics upon selecting edge application server (EAS) and user plane function (UPF). |
| | DHCPv6 Option for IPv6 ND (DHCPv6ND) |
| |
|
On some IPv6 links, clients may have a reasonable expectation that routers on the link would be willing to support DHCPv6 address/prefix delegation services without the need to first examine the M/O bits in a received Router Advertisement (RA) message. Such clients should therefore be capable of invoking the IPv6 Neighbor Discovery (IPv6ND) router discovery and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) address/prefix delegation services in a single message exchange instead of multiple. This document specifies a new IPv6ND option termed the "DHCPv6ND Option" that supports both functions in a single message exchange. |
| | An RDAP Extension for RPKI Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension, "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) through RDAP. The Internet Number Registry System (INRS) is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| | Handling inter-DC/Edge AI-related network traffic: Problem statement |
| |
| | draft-aft-ai-traffic-00.txt |
| | Date: |
09/10/2024 |
| | Authors: |
Antoine Fressancourt, Luigi Iannone, Zhe Lou, Dirk Trossen |
| | Working Group: |
Individual Submissions (none) |
|
The growth in terms of number of parameters of LLM models as well as the need to use or train those models with private or protected data will require service providers operating LLM-based services to cooperate to train, specialize or serve LLM-based services accross datacenters. Given their structure, the number of parameters they incorporate and the collective communication librairies they are built with, LLM training and inference (or serving) network traffic has specific characteristics. In that regard, understanding the specificities of AI-related workloads is critical to determine how to operate AI-based services in a federated setting across datacenters. |
| | 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. |
| | Terminology for Energy Efficiency Network Management |
| |
| | draft-bclp-green-terminology-00.txt |
| | Date: |
10/10/2024 |
| | Authors: |
Peter Liu, Mohamed Boucadair, Qin WU, Luis Contreras, Marisol Palmero |
| | Working Group: |
Individual Submissions (none) |
|
Energy-efficient network management is primary meant to enhance conventional network management with energy-related management capabilities to optimize the overall energy consumption at the level of a network. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network element and their components. This document is defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. |
| | Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications |
| |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes security considerations for short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | ICMP Extension Header Length Field |
| |
|
The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | Unsigned X.509 Certificates |
| |
|
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate does not intend to verify the signature. |
| | Enhanced Encapsulating Security Payload (EESP) |
| |
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and stateless encryption), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs (e.g., for CPU pinning and QoS support), and a crypt-offset to allow for exposing inner flow information for middlebox use. |
| | RIFT Auto-IS-IS |
| |
| | draft-head-rift-auto-is-is-00.txt |
| | Date: |
11/10/2024 |
| | Authors: |
Jordan Head, Tony Przygienda, Colby Barth, Luis Tomotaki, Brant Brockdorff |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies procedures where RIFT can automatically provision IS-IS topologies by leveraging its native no-touch ZTP architecture. |
| | Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs) |
| |
|
This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. |
| | IGP Flex Soft Dataplane |
| |
|
Advertisement of IGP Flex-Algo participation requires a dataplane context. This document defines a "soft dataplane" usable in cases where existing defined dataplanes are not suitable. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | A Profile for Autonomous System Relationship Authorization (ASRA) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA 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 customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. |
| | COSE Receipts with CCF |
| |
|
This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced by Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees. |
| | Energy Metrics For Data Networks |
| |
|
This document defines a set of energy efficiency metrics to assess and optimize the energy consumption of data networks. These metrics enable network administrators and designers to identify opportunities for energy savings, optimize network performance, and reduce the environmental impact of network operations. The proposed metrics Power Consumption per Data Rate (PCDR), Power Usage Effectiveness (PUE), Network Equipment Energy Efficiency (NEEE), and Energy Proportionality Coefficient (EPC). |
| | Resolvers and Servers for DELEG |
| |
|
This document describes the roles of resolvers and servers in the upcoming DELEG protocol. It might be useful to the DELEG WG in working on the protocol. This document will not become an RFC, but the words or ideas might be used in documents from the DELEG WG. |
| | Cross-Domain Cloud and Network Resource Management Data Model |
| |
|
This document proposes extensions to existing YANG models, as well as new YANG models, to enable the management of cross-domain cloud and network resources. The intent is to provide dynamic resource allocation mechanisms that allow services to scale efficiently across multiple cloud environments and edge computing platforms. By defining unified YANG models for both network and cloud domains, this draft addresses challenges in orchestrating and managing resources in a hybrid environment while maintaining interoperability and dynamic scaling. |
| | Publishing boundaries for IPv6 reputation |
| |
|
Applications such as e-mail track the reputation of the hosts that connect to them by IP address. Since the IPv6 address space is so large, a reputation system needs to aggregate the data for the IPs useded by a single entity. This document describes a file format a network operator can use to describe the sizes of the IP prefixes it allocates, for reputation systems to use to determine the aggregation boundaries. It also specifies an addition to the the Routing Policy Specification Language (RPSL) inetnum: class to refer to the location of the boundary file, and a method to sign boundary files. |
| | Transparent Rate Adaptation Indications for Networks (TRAIN) Protocol |
| |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and approximately what that rate limit is. |
| | A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks |
| |
| | draft-grayson-connectinfo-01.txt |
| | Date: |
05/02/2025 |
| | Authors: |
Mark Grayson, Joshua Redmore, Sri Gundavelli, Bruno Tomas, Michael Sym, Blair Bullock |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to provide servers information pertaining to the operation of an IEEE 802.11 wireless network. |
| | Gap analysis of transport protocols of high performance wide area network |
| |
|
This document analyzes the throughput performance of existing transport protocols under different implementation modes, including kernel space based mode, user space based mode, and offloading-based implementations, and concludes that existing technologies are either limited by host CPU overhead or by the complexity of offloading, and cannot guarantee high throughput approaching the bandwidth rate of the network adapter. Accordingly, this document proposes new requirements for the design of HP-WAN transport protocol. |
| | Incremental HTTP Messages |
| |
|
This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-incremental-http. |
| | BGP - Link State (BGP-LS) Advertisement of BGP Egress Peer Engineering Performance Metric Extensions |
| |
|
This document specifies a method for advertising BGP Egress Peer Engineering (EPE) Traffic Engineering (TE) Performance Metric information via BGP-LS. |
| | Erasure Encoding of Files in NFSv4.2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Version 2 Layout Type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data replication is also added to provide integrity. |
| | The Mojette Transformation for the Erasure Encoding of Files in NFSv4.2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flex file layout type version 2 further allows for erasure encoding types to provide data integrity. In this document, a new erasure encoding type for the Mojette Transformation is introduced. |
| | Application of BFD in Network Device Interconnection Authentication |
| |
|
This document extends an interface association mechanism based on BFD, which forms a network device interconnection authentication scheme. It triggers the interface down when the authentication fails, ensuring the security of the connected devices. |
| | Remote Measurement of Outbound Source Address Validation Deployment |
| |
|
Outbound IP spoofing, where attackers send packets with forged source IP addresses, poses a significant threat to Internet security. Measuring the deployment of outbound source address validation (OSAV) is critical for characterizing the vulnerability to outbound IP spoofing across the global Internet. Remote measurement of OSAV deployment offers a practical method for measuring numerous Autonomous Systems (ASes) efficiently. This document presents a method for remotely measuring the deployment status of OSAV, without cooperations from volunteers in remote networks. |
| | A YANG Data Model for Host Power Monitoring |
| |
|
This document will build a hierarchical YANG data model of SDN controller/management platform, router/switch and host to monitor the energy consumption of network devices and servers. SDN controller/ management platform obtains data from routers/switches, and routers/ switches obtain data from hosts. Therefore, in the overall hierarchical structure, the SDN controller/management platform directly obtains energy consumption data of all routers/switches, and indirectly obtains the specific energy consumption data of all hosts through routers/switches. |
| | A method for evaluating the capabilities of large language models deployed on hybrid cloud |
| |
|
This document establishes Group Standard for Large Language Model capabilities on hybrid cloud. |
| | An method of evaluating global accelerator based on cloud networking. |
| |
|
This document intends to serve as a standard for a global accelerator. |
| | Decentralized Cycle Detection |
| |
|
Decentralized Cycle Detection is node-to-node messaging protocol for finding cycles in networks. It differs from some other cycle finding algorithms in that it does not require a central coordinator or a bird's-eye view of the network. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | Generating a Letter of Agency to reflect RPKI Validity |
| |
|
Letters of Agency (LOA) are commonly used to authorise network providers to accept and propagate routing information received from others. The Resource Public Key Infrastructure (RPKI) can be used to perform a similar function, with the advantage that RPKI-signed objects can be validated automatically and in a more robust manner than manual processing of documents. However, some network operators have established processes that expect and require LOAs to be exchanged, despite their limitations. This document proposes a format for constructing a LOA in the case where RPKI validation is available, with the goal of enabling a transition to a future where LOAs are no longer needed. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
Path Computation Element Communication Protocol (PCEP) is a protocol defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various LSP identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs * A fallback to Binding label/Segment Identifier (SID) allocation by |
| | Secure UAS Stateless Network RID |
| |
|
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state. |
| | Use Cases and Requirements for Service Function Chaining based on SRv6 in cloud. |
| |
|
This document outlines the usecase for implementing Service Function Chaining(SFC) based on SRv6 in cloud, motivated by the increasing demand for collabration between cloud and network. The capabilities of SRv6 in most cloud service are not ready, such as SFC based on SRv6. If we want to realize these capabilities of SRv6 end-to-end, virtual routers(VR) can be deployed as an agent which support SRv6 in the cloud. |
| | Convertible Forms with Multiple Keys and Signatures For Use In Internet X.509 Certificates |
| |
|
This document presents a hybrid key and signature solution, which allows to integrate two public keys and/or two signatures into a single certificate. The scheme enables a single certificate to be converted between different forms, allowing an alternative public key and/or an alternative signature to be transmitted either by direct inclusion or by referencing external data. This flexibility ensures that the scheme is backward-compatible with legacy devices, while also providing enhanced security support for upgraded devices. Four CSR attributes and two new X.509v3 certificate extensions are defined, and the procedures for signing and verifying certificates containing the defined attributes and extensions are described. |
| | Simple Local Web PKI Certificate Resource Preservation Management for Internet Browser |
| |
|
The management of Web PKI certificate resources presents a challenge when the misalignment of ownership and management rights over certificate resources of one organization creating a risk of unilateral suspension and revocation by another competing organizations. This situation undermines the stability of critical infrastructure and affects the integrity of authentication systems. To address these concerns, this document proposes a mechanism that allows Internet browsers to create a customized management view of certificate resources, enabling them to override verification results from specific certification authorities as needed. This approach enhances security, facilitates stakeholder collaboration, and preserves the operational integrity of essential industry systems. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments "ietf-system-capabilities" YANG module defined in [RFC9196]. The module provides transport, encoding, and encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. |
| | A YANG model for Power Management |
| |
|
Network sustainability is a key issue facing the industry. Networks consume significant amounts of power at a time when the cost of power is rising and sensitivity about sustainability is very high. As an industry, we need to find ways to optimize the power efficiency of our networks both at a micro and macro level. We have observed that traffic levels fluctuate and when traffic ebbs there is much more capacity than is needed. Powering off portions of network elements could save a significant amount of power, but to scale and be practical, this must be automated. The natural mechanism for enabling automation would be a Yet Another Next Generation (YANG) interface, so this document proposes a YANG model for power management. |
| | Automated Certificate Management Environment (ACME) Profiles Extension |
| |
|
This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. |
| | An requirement of Cloud Network Intelligent Operation and Maintenance. |
| |
|
This document intends to serve as a standard for Cloud Network Intelligent Operation and Maintenance. |
| | A mechanism of security monitoring and management for service resources in Computing-Aware Traffic Steering (CATS) |
| |
|
The goal is to This draft proposes a mechanism to realize monitoring and management of service resources. |
| | Flexible Algorithms Exclude Node |
| |
|
Flexible Algorithms provide mechanisms for creating constraint-based paths in IGP. This document introduces a routing constraint based on Node Admin-Tags, allowing for easy exclusion of device nodes from path computation. |
| | A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions |
| |
|
A Prio Verifiable Distributed Aggregation Function is defined that supports vector or histogram addition, where the sum of the values in the contribution is less than a chosen value. |
| | Distributed Aggregation Protocol (DAP) Extensions for Improved Application of Differential Privacy |
| |
|
The Distributed Aggregation Protocol (DAP) can be a key component of a system that provides differentially-private guarantees for participants. Extensions to DAP are defined to support these guarantees. This includes bindings of reports to specific options, so that the aggregation service can better implement privacy budgeting and replay protections. |
| | Bulk Report Submission for Distributed Aggregation Protocol (DAP) |
| |
|
A bulk report submission endpoint and format are described for the Distributed Aggregation Protocol (DAP). This provides modest, but meaningful, efficiency benefits over the core protocol for cases where an intermediary is able to collect large numbers of reports. |
| | Terminology for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document compiles a glossary of terminology commonly used in discussions about enhancing lossless transmission capabilities and network performance in Wide Area Networks, especially those terms already in related IETF drafts without further explanation. To aid operators and implementers in reading contemporary drafts, this document attempts to provide an overview of terms and definitions for clarifying the current understanding, so as to facilitate the ongoing research. |
| | Requirements of NGN evolution to support multi-connection for network and cloud interworking |
| |
|
This document establishes the industry standards for Requirements of NGN evolution to support multi-connection for network and cloud interworking. |
| | Advertising Flexible Algorithm Extensions in BGP Link-State |
| |
|
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. |
| | An Updated ACK mechanism based on RDMA |
| |
|
This document proposes a new ACK mechanism for the technical gaps of RDMA used in wide-area network data transmission. The new ACK mechanism, which gets rid of the limitation of sliding window size setting and RTT measurement, can further improve the effective throughput of network transmission. |
| | Homomorphic Cryptography Protocols for Measurement Information Collection |
| |
|
Homomorphic encryption is an algorithm that allows computations to be performed on encrypted data without first having to decrypt it. This document provides a homomorphic cryptographic protocol that supports addition and multiplication in the ciphertext state. In this document, the proposed protocol can be used to protect user privacy in measurement information collection and statistics by using homomorphic encryption. And let the collector server receive the computation results without having to acknowledge the information plaintext of each individual client. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
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. |
| | Perceptive Routing Information Model |
| |
|
This docuement defines the information model for perceptive routing, which could serve as a foundational component in the implementation of perceptive routing. |
| | Pisces: Real-Time Video Transport Framework |
| |
| | draft-zheng-pisces-00.txt |
| | Date: |
18/10/2024 |
| | Authors: |
Jiaqi Zheng, Feida Liu, Yu Liu, Yi Lu, Guihai Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Pisces, an ensemble video transport framework for real-time communication. Pisces complements the benefits of rule-based and learning-based approaches, without modifying the codec layer. Pisces uses an incremental and iterative reinforcement learning model to adapt to the unseen environment. When the real environment well matches the training environment, the learning-based approach is actively working. Otherwise, the rule- based approach is used to ensure transport safety. Proactively probing network capacity simultaneously using both rule-based approach and learning models makes Pisces highly efficient and robust. Pisces can be deployed in WebRTC, which replaces the default Google congestion control algorithm. |
| | Generalized RPSL External Reference |
| |
|
The Routing Policy Specification Language (RPSL), which has operationally evolved since it was standardized in 1999, has recently added a geofeed: attribute to the innet[6]num: class to reference data external to RPSL. There is now a proposal add another attribute referencing external data, prefixlen:. This document describes a more general and extensible mechanism for external references. It also tries to anticipate the RIRs evolving from RPSL to Registration Data Access Protocol (RDAP). |
| | Designated Verifier Signatures for JOSE |
| |
|
This specification defines structures and algorithm descriptions for the use of designated verifier signatures, based on a combination of Key Agreement and Message Authentication Code, with JOSE. |
| | Robots Exclusion Protocol User Agent Purpose Extension |
| |
|
The Robots Exclusion Protocol defined in [RFC9309] specifies the user-agent rule for targeting automatic clients either by prefix matching their self-defined product token or by a global rule * that matches all clients. This document extends [RFC9309] by defining a new rule for targeting automatic clients based on the clients' purpose for accessing the service. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ TLS 1.3. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | ICMP Extensions for Environmental Information |
| |
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental sustainability information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental sustainability metrics. |
| | Environmental Sustainability Terminology and Concepts |
| |
|
This document defines a set of sustainability-related terms and concepts to be used while describing and evaluating the negative and positive environmental sustainability impacts and implications of Internet technologies. |
| | Session Description Protocol Fingerprints for Raw Public Keys in (Datagram) Transport Layer Security |
| |
|
This document defines how to negotiate the use of raw keys for TLS and DTLS with the Session Description Protocol (SDP). Raw keys are more efficient than certificates for typical uses of TLS and DTLS negotiated with SDP, without loss of security. |
| | RTP Payload for V-DMC |
| |
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a base mesh, a set of displacements, 2D representations of attributes, and an atlas. New RTP payload formats are described for the base mesh and displacement components. The RTP payload header formats enable the packetization of a video stream packet within an RTP packet payload, as well as the fragmentation of a video stream packet into multiple RTP packets. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG compatible encodings such as XML, JSON or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp caracterizing the moment when the changed data was observed. |
| | Provider Independent Addresses Aggregation |
| |
|
This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future. |
| | Issue in Route Origin Validation from Route Partial Visibility |
| |
|
In the Resource Public Key Infrastructure (RPKI), validating prefix- origin pairs using Route Origin Authorizations (ROAs) globally and performing Route Origin Validation (ROV) locally at each Autonomous System (AS) with validated ROA payloads (VRPs) can lead to inconsistent results due to partial route visibility. This document highlights how partial route visibility can turn originally non-loose ROAs into loose VRPs, outlines the causes of partial route visibility, and discusses potential solutions to mitigate the issue. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network[TMF-IG1230] or Intent-based Networking [RFC9315], and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | Client Authentication Recommendations for Encrypted DNS |
| |
| | draft-jaked-cared-00.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Tommy Jensen, Jessica Krynitsky, Jeffrey Damick, Matt Engskow, Joe Abley |
| | Working Group: |
Individual Submissions (none) |
|
Some encrypted DNS clients require anonymity from 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 wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols. |
| | Computing Aware Traffic Steering (CATS) with Generic Metric |
| |
|
Steering traffic for computing-related services considering computing resources and circumstances is discussed in CATS WG. Correspondingly, publishing services and updating computing conditions turns out to be a significant issue. It SHOULD be realized that multiple same common metrics are required from both network and service instances in order to evaluate overall performance and further achieve and fulfill appropriate traffic steering and scheduling. Therefore, an implementation for distributed CATS with generic metrics delivery and distribution based on BGP is proposed and discussed in this draft. |
| | Use Cases for IPv6 Network End to End Monitoring |
| |
|
End to end monitoring of IPv6 network is crucial for telecom operator network analysis.This document provides a detailed introduction to the use cases of end to end monitoring in IPv6 network, in order to explore end to end monitoring methods. |
| | Symmetric HTTP/2 Extension |
| |
|
This draft defines an HTTP/2 [RFC9113] extension to support Symmetric HTTP, which makes a simplifying assumption that the client-side HTTP server is only accessible and addressible by the server that accepted the HTTP/2 connection. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/joshco/sh2. |
| | IPv6 Network Monitoring Deployment Analysis |
| |
|
This document outlines the current approaches to monitoring IPv6 deployment and proposes potential new requirements to advance IPv6 deployment further. It identifies common problems with current IPv6 monitoring methods and suggests considerations for future improvements. |
| | SR based Loop-free implementation |
| |
|
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
|
This document describes an approach where ACME Client can prove possession of a Remote Attestation Result to an ACME Server. |
| | SRv6 NET-PGM extension: Compressed BSID Insertion |
| |
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-C-SID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-C-SID flavor. |
| | Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing |
| |
| | draft-akiyama-cmg-00.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Kuon Akiyama, Ryoichi Shinkuma |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics. |
| | SRv6 for Power Grid |
| |
|
This document outlines the deployment of Segment Routing over IPv6 (SRv6) in the power grid communication network, including power grid services, requirement analysis, network structure and different srv6 deployment scenarios. |
| | Advertisement of Multi-Sourced SAV Rules using BGP Link-State |
| |
|
This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rule monitoring and management. |
| | Scenarios and Deployment Considerations for High Performance Wide Area Network |
| |
|
This document describes the typical scenarios and deployment considerations for High Performance Wide Area Networks (HP-WANs). It also provides simulation results for data transmission in WANs and analyses the impacts on throughput.. |
| | A Use Case of Network Operation for Telecom Cloud |
| |
|
This document discusses the network operation issues of telecom cloud. It first introduces a typical use case of network for telecom cloud, then illustrates the requirements for network operation for telecom cloud from the perspective of TSP, and proposes a general network operation model for telecom cloud. It also analyzes the gap based on the current technological status. |
| | Extensions to IOAM Trace Option for Carrying Fixed-Size Data |
| |
|
The IOAM Trace-Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the transited IOAM- capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed-size data, the length of this kind of data is fixed and doesn't vary with the transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. |
| | Framework for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document proposes a comprehensive framework to address the challenges of efficient, reliable, and cost-effective large volume data transmission over Wide Area Networks (WANs). The framework focuses on planning and managing traffic paths, network slicing, and utilizing multi-level network buffers. It introduces dynamic path scheduling and advanced resource allocation techniques to optimize network resouce and minimize congestion. By leveraging cross-device buffer coordination and real-time adjustments, the framework ensures high throughput and low latency, meeting the demands of modern, data- intensive applications while providing a robust solution for large- scale data transmission. |
| | YANG Templates |
| |
|
NETCONF and RESTCONF protocols provide programmatic operation interfaces for accessing configuration data modeled by YANG. This document defines the use of YANG-based configuration template mechanism so that the configuration data could be defined as template and applied repeatedly to avoid the redundant definition of identical Configuration and ensure consistency of it. |
| | In-Network Congestion Notification |
| |
|
This document describes an in-network congestion notification mechanism for the provider network, to enable the real-time Tactical Traffic Engineering on the provider edge node. |
| | A YANG Data Model of Performance Management Streaming |
| |
|
This document provides a YANG data model of performance management streaming in network equipment. It defines types of parameters, and their measurements and reporting methods by periodic and event notifications. |
| | Use Cases and Requirements for SCONE in Massive Data Transmission |
| |
|
This document outlines a use case for Standard Communication with Network Elements (SCONE) in the context of massive data transmission (MDT). From the described use case, it derives a set of signaling requirements for the communication between applications and network elements. |
| | Analysis of Service Management Interface for Cloud-network Convergence |
| |
|
This document analyzes the cloud-network convergence service management interface. |
| | Post-Handshake Authentication via PAKE for TLS 1.3 |
| |
|
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as a post-handshake authentication for TLS 1.3, and that supports PAKE algorithms negotiation and optional channel binding. |
| | PCEP Extension for Fine Grain Optical Transport Network (fgOTN) |
| |
|
This document introduces the PCEP extension used for computed fgOTN path from the PCE to the PCC. |
| | IFIT-based anomaly monitoring and tracing in data circulation |
| |
|
This document proposes a deployment scheme of IFIT-based anomaly monitoring and tracing in data circulation. Use cases and requirements are discussed, and a deployment scheme is described in detail. |
| | Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document defines a format for transport of hints about Trust Anchors of trusted third parties when using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | Populating a list of YANG data nodes using templates |
| |
|
This document presents a modeling technique for configuring large scale devices in a compact way, when the device contains many similar data node patterns. A device here refers to any such entity that acts as a netconf server. This is realized by instructing the device to locally generate repetitive patterns of data nodes from a master copy called 'template' that is configured in the device. This approach is both convenient and efficient, as it minimizes the size of the running data store and reduces network provisioning time. It leverages existing YANG specification features and can be implemented with standard, off-the-shelf tools. |
| | SCONE Real Time Communication Requirement |
| |
|
In real-time communication (RTC) applications, low latency is essential, but unstable network conditions make it challenging. Traditional control loop reacts slowly and inaccurately to network changes. A new approach is proposed, communicating bandwidth and queue information from the bottleneck to the end-host for more accurate control. |
| | EPP XML to RPP JSON conversion rules |
| |
|
This document describes the rules for converting The Extensible Provisioning Protocol (EPP) [RFC5730] XML based messages to a JSON [RFC8259] for use with the RESTful Provisioning Protocol (RPP). |
| | Automation Scenarios and Requirements for Level 4 Autonomous Networking (AN) |
| |
|
This document describes OTN-WDM service automation and collaboration scenarios in transport networks and defines the functional requirements of domain controller in these scenarios. |
| | A congestion control mechanism based on distributed AIDC lossless network |
| |
|
This document proposes a congestion control mechanism based on distributed AIDC lossless network. It can effectively solve the problem of declining model training performance due to congestion and packet loss on long-distance links when training large models across multiple data centers within a region. In addition, this document outlines the practice scenario of this congestion control mechanism. |
| | Applying BGP-LS Segment Routing Extensions to BGP-LS SPF |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing (SR) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. In some networks, it may be useful to enable SR based source routing mechanism together with BGP-LS SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for segment routing to the BGP-LS SPF SAFI. |
| | Fast Fault Tolerance Architecture for Programmable Datacenter Networks |
| |
| | draft-fft-architecture-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Dan Li, Kaihui Gao, Shuai Wang, Li Chen, Xuesong Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces a fast rerouting architecture for enhancing network resilience through rapid failure detection and swift traffic rerouting within the programmable data plane, leveraging in-band network telemetry and source routing. Unlike traditional methods that rely on the control plane and face significant delays in traffic rerouting, the proposed architecture utilizes a white-box modeling of the data plane to distinguish and analyze packet losses accurately, enabling immediate identification for link failures (including black- hole and gray failures). By utilizing real-time telemetry and SR- based rerouting, the proposed solution significantly reduces rerouting times to a few milliseconds, offering a substantial improvement over existing practices and marking a pivotal advancement in fault tolerance of datacenter networks. |
| | Serialization of MoQ Objects to Files |
| |
|
This specification provides a way to save the meta data about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the meta data and payload data allow the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to client. |
| | On-Path Proxy Discovery |
| |
|
This document surveys possibilities for On-Path Proxy Discovery (OPPD). It is meant to help the conversation in a planned side meeting at IETF-121 in Dublin (see the github page linked under "About This Document" for coordinates). The draft title indicates PANRG as a target of this document just because we thought that PANRG should be informed. What a suitable target is, and if this is even the right type of document, should all be discussed at the side meeting. |
| | Applicability of TVR YANG Data Models for Scheduling of Network Resources |
| |
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include mobility networks with moving nodes, resource constraints such as power, and tidal traffic demand networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. |
| | Framework of Distributed AIDC Network |
| |
|
With the rapid development of large language models, it puts forward higher requirements for the networking scale of data centers. Distributed model training has been proposed to shorten the training time and relieve the resource demand in a single data center.This document proposes a framework to address the challenge of efficient lossless interconnection and reliable data transmission between multiple data centers, which can connect multiple data centers to form a larger cluster through network connection. The document further conducts in-depth research on the key technologies and application scenarios of this distributed AIDC network. |
| | Calibration of Measured Time Values between Network Elements |
| |
|
Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. This draft proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. |
| | RSVP Cryptographic Authentication,Version 2 |
| |
|
This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097. |
| | Extensions to BIER Tree Engineering (BIER-TE) for Large Multicast Domains and 1:1 Protection |
| |
|
BIER-TE extends BIER with tree engineering capabilities and can be supported by almost the same hardware. However, a bitstring in BIER- TE hold bits for BFERs and links, which effects that the size of supportable topologies in terms of BFERs is smaller for BIER-TE than for BIER. While for BIER, subsets can be utilized to improve scaling to large multicast domains, this mechanism requires adaptation for BIER-TE. In this document, requirements for BIER-TE subsets are defined, a mechanism is described for how BIER-TE packets can reach their subsets using tunneling, and 1:1 protection for the entire BIER-TE multicast tree is explained. The concept utilizes egress protection for reaching a subset when the ingress BFIR of the subset fails. |
| | Interfaces of In-Network Functions in Data Center Networking |
| |
|
In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Functions (INF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these INFs. This document focuses on the applicability of INFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these INFs. |
| | Inter-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | MLS Associated parties |
| |
|
The Messaging Layer Security (MLS) protocol allows a group of clients to exchange symmetric keys, agree on group state and send application messages. The main purpose of an MLS group is thus to facilitate agreement on group state and key material between the members of the group. In some cases, however, it is useful to share agreement on the (public) group state, as well as key material with another party that is not a full member of the group. This document describes a safe extension to do just that. |
| | Flexicast QUIC: combining unicast and multicast in a single QUIC connection |
| |
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and multicast distribution trees. |
| | Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane |
| |
|
This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability. |
| | Merkle Mountain Range for Immediately Verifiable and Replicable Commitments |
| |
|
This specification describes the COSE encoding of proofs for post- order traversal binary Merkle trees, also known as history trees and Merkle mountain ranges. Proving and verifying are defined in terms of the cryptographic asynchronous accumulator described by ReyzinYakoubov (https://eprint.iacr.org/2015/718.pdf). The technical advantages of post-order traversal binary Merkle trees are discussed in CrosbyWallachStorage (https://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf) and PostOrderTlog (https://research.swtch.com/tlog#appendix_a). |
| | Analysis for the Adverse Effects of LEO Mobility on Internet Congestion Control |
| |
| | draft-lai-ccwg-lsncc-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Qi Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a performance analysis on various congestion control algorithms(CCAs) in an operational low-earth orbit (LEO) satellite network (LSN). Internet CCAs are expected to perform well in any Internet path, including those paths with LEO satellite links. Our analysis results reveal that existing CCAs struggle to deal with the drastic network variations caused by the mobility of LEO satellites, resulting in poor link utilization or high latency. Further, this document discusses the key challenges of achieving high throughput and low latency for end-to-end connections over an LSN, and provides useful information when the LSN-specific congestion control principles for the Internet is standardized in the future. |
| | MLS Split Commits |
| |
|
This document describes an extension to the MLS protocol [RFC940] that improves its efficiency in terms of per-member download size. This comes at essentially no cost. In essence, this document defines a new message type called split commit which replaces regular MLS commits. Unlike regular commits, a split commit can be "split" by the Delivery Service (DS) into much smaller per-member commits, one for each receiving member. The size of a per-member commit is always logarithmic in the group size, while the size of a regular MLS commit can be linear. This extension works in settings with a DS that can do the splitting which can be demanding with encrypted MLS handshake messages. This is motivated by academic research [KKP22], [HKPPW22], [AHKM22]. |
| | DHCPv4 Option for IPv4 routes with IPv6 nexthops |
| |
|
// This draft lives at https://github.com/eqvinox/dhc-route4via6 As a result of the shortage of IPv4 addresses, installations are increasingly recovering IPv4 addresses from uses where they are not strictly necessary. One such situation is in establishing next hops for IPv4 routes, replacing this use with IPv6 addresses. This document describes how to provision DHCP-configured hosts with their routes in such a situation. |
| | A YANG Data Model for Passive Network Inventory |
| |
|
This document presents a YANG data model for passive device inventory information. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. |
| | Dynamic Network Adjustments for Cloud Service Scaling |
| |
|
This document defines a framework for dynamically adjusting network- wide load balancing policies in response to cloud service scaling events, addressing key challenges faced by Telecom Cloud Service Providers (TCSPs). As cloud services scale, increase traffic, or relocate workloads across distributed edge and core clouds, network policies must adapt in real time to maintain optimal performance and ensure compliance with strict service level objectives (SLOs). Current manual network adjustments are often slow, error prone, and insufficient for the dynamic nature of cloud environments. |
| | MLS Wire Formats for PublicMessage and PrivateMessage without authenticated_data |
| |
|
This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-green-api-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Alejandro Muniz, Marisol Palmero, Fernando Munoz, Jan Lindblad |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | YANG Data Model for BGP about RPKI |
| |
| | draft-liu-idr-bgp-rpki-yang-01.txt |
| | Date: |
22/01/2025 |
| | 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 BGP information about Resource Public Key Infrastructure (RPKI). |
| | Framework for Getting Ready for Energy-Efficient Networking(GREEN) |
| |
|
This document describes a framework for a framework for Getting Ready for Energy-Efficient Networking(GREEN). |
| | A Use case for Green Computing-Aware Traffic Steering |
| |
|
This draft describes a compute-aware use case for services with green energy requirements. This use case considers both network, computation and energy metrics when selecting a service instance. |
| | Initial Considerations about QDKN Protocols |
| |
| | draft-danet-qkdn-considerations-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Martin Stiemerling, Fabian Seidl, Malte Bauch, Neil-Jocelyn Schark, Johanna Henrich |
| | Working Group: |
Individual Submissions (none) |
|
Quantum communication modules connected via a link, either via fiber or free-space communications, have been used since a while to distribute random numbers as secure keys, but there are other use cases, such as time synchronization. By today, a number of research and industrial efforts are underway to built complete networks, primary for secure key distribution, i.e., so-called Quantum Key Distribution Networks (QKDN). This memo briefly explores the space of QKDNs and identifies spots of potentials interest to develop standardized protocols specific for such networks. |
| | A new QUIC version for network property communication |
| |
|
This document describes a new QUIC version. The proposed wire format and a set of procedures can be used to communicate throughput advice between an endpoint and an on-path network element. Throughput advice are sent in QUIC packets of a new QUIC version. These QUIC packets are sent adjecent to established QUIC version 1 and 2 connections, within the same UDP 4-tuple. |
| | Signalling Key State Via DNS EDNS(0) OPT |
| |
|
This document introduces the KeyState EDNS(0) option code, to enable the exchange of SIG(0) key state information between DNS entities via the DNS protocol. The KeyState option allows DNS clients and servers to include key state data in both queries and responses, facilitating mutual awareness of SIG(0) key status between child and parent zones. This mechanism addresses the challenges of maintaining synchronization of SIG(0) keys used for securing DNS UPDATE messages, thereby enhancing the efficiency and reliability of DNS operations that require coordinated key management. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-opt-transaction-state (https://github.com/johanix/draft-berra-dnsop-transaction-state-00). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | UDP Option Extension for 5G XR Media Services |
| |
|
Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in 3GPP. The service features at achieving high data rate, high reliability and low latency. The multiple streams of an XRM service use IP sessions to transport media contents with the provisioning of advanced QoS settings. The XRM Metadata or PDU Set QoS marking is used to differentiate the PDU Set requirements to the 5GS. RTP header extension (HE), as defined by 3GPP, can be used to transport XRM Metadata for un-encrypted media streams, while the encrypted XRM streams post challenges for UPFs to extract the Metadata. This draft proposes to use the IETF UDP Option extension, by defining a new SAFE type, to help enhance the carry & transport of encrypted XRM Metadata. |
| | IPv6 Address Accountability Considerations |
| |
|
Hosts in IPv4 networks typically acquire addresses by use of DHCP, and retain that address and only that address while the DHCP lease remains valid. In IPv6 networks, hosts may use DHCPv6, but may instead autoconfigure their own global address(es), and potentially use many privacy addresses over time. This behaviour places an additional burden on network operators who require address accountability for their users and devices. There has been some discussion of this issue on various mail lists; this text attempts to capture the issues to encourage further discussion. |
| | SRv6 Deployment Options |
| |
|
This document presents various options to help provide deployment direction to those whose networks will be upgraded to an SRv6 environment. Whether the existing network is IPv4, IPv6, MPLS, SR- MPLS or other, this draft provides direction on how to seemlessly upgrade to SRv6. |
| | YANG Data Models for Security Configuration Check |
| |
|
Security configuration refers to the status setting of product security features/functions to reduce network security risks during product use. This document defines YANG data models for the security configuration check. |
| | Multi-Perspective Issuance Corroboration (MPIC) Service |
| |
|
This memo defines an API for Multi-Perspective Issuance Corroboration (MPIC) services to facilitate domain control validation (DCV) from multiple network perspectives. MPIC enhances the security of publicly-trusted certificate issuance by mitigating the risk of localized, equally-specific BGP hijacking attacks that can undermine traditional DCV methods permitted by the CA/Browser Forum Baseline Requirements for TLS Server Certificates. This API enables Certification Authorities (CAs) to more reliably integrate with external MPIC providers, promoting a more robust and resilient Web PKI ecosystem. The API design prioritizes flexibility, scalability, and interoperability, allowing for diverse implementations and deployment models. This standardization effort is driven by the need to consistently address vulnerabilities in the domain validation process highlighted by recent research and real-world attacks, as reflected in Ballot SC-067 V3 of the CA/Browser Forum's Server Certificate Working Group. |
| | Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | An Architecture for IP in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. The IP protocol stack used on Internet is based on assumptions of shorter delays and mostly uninterrupted communications. This document describes the architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links, signaling buffer storage near capacity, adjusting transport protocols configuration and application protocols timers. This architecture applies to Moon, Mars or in general interplanetary networking. |
| | Efficient Updates to Messaging Layer Security GroupContext Extension |
| |
|
The Messaging Layer Security (MLS) protocol allows the members of the group to agree on a set of GroupContext extensions. MLS includes a mechanism to do a wholesale replacements of all GroupContext extensions, but not to modify individual extensions. In this document, we define a mechanism that allows implementations to add, update, and remove each element of the GroupContext individually. This also makes it practical for applications using MLS to exploit this feature of MLS to ensure that the group members are in agreement on the state of the application in addition to MLS-related state. |
| | BGP SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | Simple Time Over MoQ Protocol (STOMP) |
| |
|
This document describes Simple Time Over MoQ Protocol (STOMP), a protocol for sending the local time and, optionally, location information via Media Over QUIC Transport (MOQT) protocol [I-D.ietf-moq-transport]. Such information enables observing endpoints to measure latencies and monitor health of MOQT delivery network from different geographical locations. |
| | Multi-Perspective Issuance Corroboration (MPIC) Service |
| |
|
This memo defines an API for Multi-Perspective Issuance Corroboration (MPIC) services to facilitate domain control validation (DCV) from multiple network perspectives. MPIC enhances the security of publicly-trusted certificate issuance by mitigating the risk of localized, equally-specific BGP hijacking attacks that can undermine traditional DCV methods permitted by the CA/Browser Forum Baseline Requirements for TLS Server Certificates. This API enables Certification Authorities (CAs) to more reliably integrate with external MPIC providers, promoting a more robust and resilient Web PKI ecosystem. The API design prioritizes flexibility, scalability, and interoperability, allowing for diverse implementations and deployment models. This standardization effort is driven by the need to consistently address vulnerabilities in the domain validation process highlighted by recent research and real-world attacks, as reflected in Ballot SC-067 V3 of the CA/Browser Forum's Server Certificate Working Group. |
| | Composite Token Claims |
| |
|
Composition claims are CBOR Web Token claims that define logical relationships between sets of claims and provide for private claim values via encryption. |
| | A Password Authenticated Key Exchange Extension for TLS 1.3 |
| |
| | draft-bmw-tls-pake13-01.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Laura Bauman, David Benjamin, Samir Menon, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. |
| | Requirements for Energy Efficiency Management |
| |
|
This document delineates the requirements for standards specifications in Energy Efficiency Management, extending the foundational work of RFC6988 and incorporating recent insights from operator requirements and the GREEN BoF discussions. Eleven years after the publication of RFC6988, this document reassesses and updates the requirements to align with contemporary needs. The primary objectives of this draft, which are listed in the goals and scope with the creation of the GREEN WG charter, is focusing on two main targets: (1) collecting and updating requirements for the management of energy-efficient networks, and (2) defining use cases for managing energy-efficient networks. This draft merges the drafts [rfc6988bis-green] and [green-bof-reqs]. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-terms-ucs-and-reqs |
| | MoQ Media Interop |
| |
|
This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT]. |
| | DKIM2 Why DKIM needs replacing,and what a replacement would look like |
| |
|
This memo provides a rationale and outline design for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. |
| | SPACE - Scalable Pubsub,Asymmetric and CachEd transport for Deep Space communications |
| |
|
Deep Space communications can be benefited by a publish/subscribe, store-and-forward and asymmetric delivery network over IP that allows communications across links with high latencies and dynamic network conditions (losses and high bit error rates). This specification proposes to use Media over QUIC Transport (MOQT) [MoQTransport] as the common delivery protocol for deep space communications. |
| | YANG-Push Operational Data Observability Enhancements |
| |
|
*This version of the document is aimed to be a base reference point to compare against to see how YANG Push Lite compares to the two core RFCs [RFC8639] & [RFC8641] that it is based on. The next draft revision would serve as a better starting point to see the proposed protocol & data model for YANG Push Lite.* YANG Push Lite is a simplified specification of YANG Push, specifically optimized for observability of operational data. This early draft proposes some enhancements to YANG-Push to optimize its behavior for operational data telemetry. It also lists some additional issues that could potentially be discussed if there is further interest in this work, in particular whether we should be attempting extensions to YANG-Push (as this document is currently framed) or instead should attempt to define a new 'YANG-Push lite'. |
| | Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness |
| |
|
When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Consequently, they may continue to use addresses which are not valid for that link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC. |
| | Data Unit Groups for DetNet-Enabled Networks |
| |
|
This document provides the description of an Internet Protocol (IP) Version 6 (IPv6) extension header allowing DetNet routers to determine the relative importance between packets of the same flow, which enables gracefully dropping packets in case of congestion. This behaviour can for example be useful for media flows, where different application units can have very different impact on the quality of experience of the user. This document aims primarily at extending the DetNet IP Data Plane in an initial revision of this draft, and may be extended to Multi-Protocol Label Switching (MPLS) and MPLS over User Datagram Protocol (UDP)/IP data plane options in future revisions. |
| | VCON for MIMI Messages |
| |
|
This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (MIMI) content format. |
| | BGP Route Type Capability |
| |
|
BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. |
| | MoQ Chat |
| |
|
MoQ Chat (moq-chat) is a simple text based protocol for exercising MoQ Transport. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) ) |
| |
|
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based method to authenticate DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. |
| | DHCP Option Concatenation Considerations |
| |
|
DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by [RFC3396]. However, this mechanism is required to be supported for all options. This leads to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences. |
| | Robots Exclusion Protocol Extension to manage AI content use |
| |
|
This document extends RFC9309 by specifying additional rules for controlling usage of the content in the field of Artificial Intelligence (AI). |
| | Green Networking Metrics for Environmentally Sustainable Networking |
| |
| | draft-cx-green-green-metrics-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Alexander Clemm, Carlos Pignataro, Eve Schooler, Laurent Ciavaglia, Ali Rezaki, Greg Mirsky, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document explains the need for network instrumentation that allows to assess a number of sustainability-related attributes such as power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's "greenness" accordingly. Note: This document replaces an earlier document in OPSAWG as the recently-established GREEN provides for a more fitting landing spot. |
| | Service Funciton Orchestration Interface for Cloud Network Collaboration |
| |
|
This document focuses on interface requirements between network controller and service function orchestrator, as well as between cloud controller and service function orchestrator. |
| | Service Announcement Methods for CATS |
| |
|
This document introduces network-layer service announcement solutions based on architecture defined in [I-D.ldbc-cats-framework]. In particular, the scheme describes how to disseminate computing service information to clients and the control plane through service announcement messages. This draft also proposes to classify the attributes used to describe computing services and analyzes several service querying mechanisms. |
| | SAVI in a LISP network |
| |
|
This document specifies the procedures for Source Address Validation of LISP Endpoint Identifiers (EID). The implementation of these mechanisms provides endpoint detection, on-boarding and roaming support in LISP networks, while protecting against IP address spoofing. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides useful and secure semantics for RTR Protocol in particular as a single connection could carry multiple requests over streams, enabling much better efficiency and performance for both peers. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | TLS Client Puzzles Extension |
| |
| | draft-venhoek-tls-client-puzzles-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
David Venhoek, -, Marc Schoolderman, Erik Nygren, Samuel Erb, Alex Biryukov, Dmitry Khovratovich, Ari Juels |
| | Working Group: |
Individual Submissions (none) |
|
Client puzzles allow a TLS server to defend itself against asymmetric DDoS attacks. In particular, it allows a server to request clients perform a selected amount of computation prior to the server performing expensive cryptographic operations. This allows servers to employ a layered defense that represents an improvement over pure rate-limiting strategies. Client puzzles are implemented as an extension to TLS 1.3 [RFC8446] wherein a server can issue a HelloRetryRequest containing the puzzle as an extension. The client must then resend its ClientHello with the puzzle results in the extension. |
| | Interfaces of In-Network Functions in Data Center Networking |
| |
|
In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Functions (INF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these INFs. This document focuses on the applicability of INFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these INFs. |
| | A method for describing changes made to an email |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE 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 SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using the SCONE protocol (to be defined by the IETF), it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | SCONE Net Neutrality |
| |
|
This document provides a response to the question of whether SCONE can be used to undermine Net Neutrality provisions for network users. It proposes guardrails to ensure Net Neutrality principles are maintained. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | Domain Name System in Mostly Isolated Networks |
| |
|
This document lists operational methods to enable local DNS name resolving on an isolated network, where that network have intermittent reachability to Internet and/or have very long delays, such as deep space networks, disabling the real-time query and response flow to the authoritative name servers on Internet. |
| | Domain Transfer Authorization Using Cryptographic Signatures |
| |
|
This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a cryptographic signature-based validation system that enables authorization based on PKIs (Public Key Identification) and hands over control of the domain to a specific next controller identified by their PKI. The process is designed to be fully backward compatible with existing EPP systems through staged incremental upgrades. |
| | Current practices for new cryptography at the IETF |
| |
|
This document describes the current practices for handling new cryptography within the IETF. Some of these practices are informal and depend on individuals in certain relevant roles, such as Working Group Chairs, the Security Area Directors and the Independent Stream Editor. This document is intended to increase consistency and transparency in how the IETF handles new cryptography, such as new algorithms, ciphers and new primitives or combiners, by providing a reference for the cryptographic practices within the IETF. This document does not describe any new policies and does not prohibit exceptions in the described current practices. |
| | A YANG module for entitlement inventory |
| |
|
This document proposes a YANG module with an inventory of entitlements. The model helps manage details about entitlements, such as their scope, how they are assigned, and when they expire. The model introduces the a descriptive definition of features and use restriction that can help a entitlement admistration an understanding of the state of their assets and the capabilities available across the network. |
| | SCONE Video Optimization Requirements |
| |
|
These are the requirements for the "Video Optimization" use-case for SCONE, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mjoras/sadcdn-video-optimization-requirements. |
| | Future Research Directions on Energy-Aware Security Mechanisms |
| |
|
With the onset of the climate emergency, all areas of human activity are expected to continuously assess their Greenhouse Gas emissions and encourage the use of clean energy sources as much as possible. The current discussion on green networking in the Network Management research field still needs to be expanded to the adjoined areas, such as Network Security. This document summarizes the security considerations of the existing works and outlines possible research directions for energy-aware security mechanisms. |
| | SRv6 Inter Domain Routing Architecture |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | SRv6 Inter Domain Routing Use Cases |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | HTTP Version Translation of the Capsule Protocol |
| |
|
This draft specifies how HTTP intermediaries can translate the Capsule Protocol between HTTP versions. 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-kb-capsule-conversion/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/capsule-conversion. |
| | Means of Compliance for DRIP Entity Tags as UAS RID Identifiers |
| |
|
This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-dutt-nvo3-rfc7348bis-00.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Kenneth Duda, Puneet Agarwal, Larry Kreeger, T. Sridhar, Mike Bursell, Chris Wright, Ali Sajassi |
| | Working Group: |
Individual Submissions (none) |
|
This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. |
| | DNS Filtering Details for Applications |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism that enable applications to convey the details of some filtering incidents to their users. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. |
| | SPICE Traceability CWT Claims |
| |
|
This document proposes additional claims for CBOR Web Tokens (CWT) to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims aim to standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. |
| | DNS Servers MUST Shuffle Answers |
| |
|
DNS Resource Records (DNS RR) are often used in the order that they are returned. This means that if there are more than one RR in a RR set, then they should be returned in a random order, to reduce bias in how the answers are used. |
| | Palimpsest |
| |
|
This document provides an overview of the Palimpsest structured collaboration system. Palimpsest facilitates review of documents through reactions tagged with weak semantics defining processing steps for the reaction. Documents are grouped into projects with a common set of allowed semantic moves and processing steps. This allows the revie |
| | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
|
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT Nodes". Each DDT Node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT Nodes to which more-specific EID-prefixes are delegated. This document obsoletes RFC 8111. |
| | Procedure for YANG SID Allocation |
| |
|
This document defines a standardized procedure for the allocation of YANG SID Ranges (YANG Schema Item iDentifier ranges) and the subsequent assignment of SIDs for IETF RFCs with YANG files. |
| | SID Space (5f00::/16) Inter-domain Addressing Recommendations |
| |
|
This specification recommends a specific structured use of the SRv6 SIDs prefix in support of Inter-Domain SRv6 networks. The core of the proposal is to structure the address space by Autonomous System Number (ASN). Use of this proposed structure is entirely voluntary. Voluntary use of this structure aids SRv6 operations while preserving the ability to use this prefix across cooperating SRv6 domains, but not across the general Internet. |
| | Two DNS Resolver Information Keys for DNSSEC and DNS64 |
| |
|
This document specifies two DNS Resolver Information Keys (RFC 9606) for DNSSEC validation capability, "dnssecval" and DNS64 synthesis, "dns64". |
| | Making BMP fruible offline |
| |
|
BMP (BGP Monitoring Protocol) [RFC7854] is perfectly suited for real- time consumption but less ideal for off-wire historical purposes. The main issue is the dependence that parsing BGP Update PDUs has on knowing which capabilities have been agreed when establishing the BGP session with the peers, which could have happened long time ago (days, weeks, months). This document defines a new optional BMP message type, called Peer Summary, that carries a summary of the established BGP sessions along with their capabilities and that is intended to be injected in the BMP feed at configurable time intervals and/or ad-hoc whenever it is felt necessary to improve fruition of BMP data offline. |
| | Computing Resource Authenticity Evaluation in Computing-Aware Traffic Steering |
| |
|
This draft introduces an evaluation scheme for computing resource authenticity. The scheme aims to verify and evaluate the authenticity of computing resources in the network using application layer method. This draft describes the basic principle of the scheme and authentication mechanism. |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
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 IPv6 stateless address autoconfiguration. |
| | OAuth 2.0 Client ID Scheme |
| |
|
This specification defines the concept of a Client Identifier Scheme to enable Authorization Servers and Clients to use more than one mechanism to obtain and validate Client metadata. |
| | Robots.txt update proposal |
| |
|
This document proposes updates to the robots.txt standard to accommodate AI-specific crawlers, introducing a syntax for user-agent identification and policy differentiation. It aims to enhance the management of web content access by AI systems, distinguishing between training and inference activities. |
| | Attester Issuer Protocol |
| |
|
TODO Abstract 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://smhendrickson.github.io/draft-hendrickson-pp-attesterissuer/ draft-hendrickson-pp-attesterissuer.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- hendrickson-pp-attesterissuer/. Source for this draft and an issue tracker can be found at https://github.com/smhendrickson/draft-hendrickson-pp-attesterissuer. |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. |
| | A Template for IANA Cryptographic Registries |
| |
|
This document provides recommendations for how IETF Working Groups should create IANA registries that are related to cryptographic algorithms. It is based on the lessons learned from the TLS registries over the years. |
| | Hybrid Signature Considerations |
| |
|
This document discusses how and when to use hybrid post-quantum/ traditional signatures, and when not to, including prehashing and key use. |
| | PCEP Extensions of SR Policy for Headend Behavior |
| |
|
A Segment Routing (SR) Policy [RFC9256] is a non-empty set of SR Candidate Paths, that share the same tuple. [I-D.draft-ietf-pce-segment-routing-policy-cp] extends [RFC8664] to fully support the SR Policy construct. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. [RFC8986] defines H. Encaps behavior, H. Encaps.Red behavior, H. Encaps.L2 behavior, and H. Encaps.L2.Red behavior for SR policy. This document defines extensions to PCEP to distribute SR policies carrying headend behavior. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
This document specifies how the post-quantum signature scheme ML-DSA [FIPS204], in combination with traditional algorithms RSA- PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for authentication in TLS 1.3. The composite ML-DSA approach is beneficial in deployments where operators seek additional protection against potential breaks or catastrophic bugs in ML-DSA. |
| | CAA Security Tag for Cryptographic Domain Validation |
| |
| | draft-birgelee-lamps-caa-security-00.txt |
| | Date: |
14/11/2024 |
| | Authors: |
Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal |
| | Working Group: |
Individual Submissions (none) |
|
CAA "security" tags are a type of CAA record (defined in RFC 6844) with the critical flag set that specify that for a certificate to be issued, the issuance process must be conducted in a manner that is robust against global man-in-the-middle adversaries by leveraging authenticated communication between a CA and a domain. Cryptographic domain validation procedures are authenticated and resilient against attacks by both on-path and off-path network attackers which may be between the CA and the domain contained in the certificate. This document defines the syntax of "security" CAA records as well as acceptable means for validating domains in a cryptographic manner. |
| | IGP based Network Computing Combined Optimization |
| |
|
This document describes the scenario and procedures that can be used to accomplish the IGP based network and computing combined optimization within the IS-IS or OSPF domain. |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further request. |
| | Controlling IP Fragmentation on Common Platforms |
| |
|
When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. |
| | PSI based on ECDH |
| |
| | draft-wang-ppm-ecdh-psi-01.txt |
| | Date: |
16/02/2025 |
| | Authors: |
wangyuchen, Wenting, Yufei Lu, Cheng Hong, Jin Peng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Elliptic Curve Diffie-Hellman Private Set Intersection (ECDH-PSI) for 2 participants. It instantiates the classical Meadows match-making protocol with standard elliptic curves and hash-to-curve methods, enabling the participants to find common records in a privacy-respecting way. In ECDH-PSI, records are encoded to points on an elliptic curve, and masked by the private keys of both participants. To compute the intersection, a participant only uses the jointly masked datasets and its original dataset locally, which prevents its partner from learning the private records not in the intersection. |
| | Use of ML-DSA in TLS 1.3 |
| |
|
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. 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://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/tls-mldsa. |
| | Use of SLH-DSA in TLS 1.3 |
| |
| | draft-reddy-tls-slhdsa-00.txt |
| | Date: |
15/11/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. |
| | ECDP: Elliptic Curve Data Protocol |
| |
|
This document specifies the Elliptic Curve Data Protocol (ECDP), a peer-to-peer (P2P) communication protocol tailored for decentralized networks. ECDP utilizes elliptic curve cryptography (ECC) for encryption, employs the Elliptic Curve Digital Signature Algorithm (ECDSA) for message authentication, and leverages the Diffie-Hellman key exchange using elliptic curves for secure session initialization. The protocol supports a variety of elliptic curves (e.g., secp256k1, secp384r1) with varying key sizes, and is designed to operate over both TCP and UDP. Additionally, it utilizes SHA-256 or SHA-512 for cryptographic hash verification to ensure message integrity. |
| | RATS Message Types |
| |
|
This establishes that RATs messages types should be identified by either CoAP Content-Format or Media Type (MIME type) or both. CBOR tags and other type mechanisms should not be used. This updates EAT, in a backwards-compatible way, so that the type of EAT nested tokens can be identified by CoAP Content-Format and Media Type. |
| | Throughput Advice Object for SCONE |
| |
|
Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.). |
| | The Contextualized REST Architecture |
| |
|
The REST architecture is extremely popular in modern computing environments. A benefit it provides is that each request can be serviced by independent server side components such as different instances of web servers or different instances of serverless request handlers. The lack of any context associated with a request means that the client has to provide the entire context with every request. In monolithic server-side architectures the client typically only provides an identifier to a previously established "session" on the server side, which is retrieved from a persistent storage such as a database. However, this strategy often does not work in microservices architectures, where the persistent storage may be many hops away from the server-side components that handle the incoming REST API requests. As a result, REST APIs are used between services and each request is required to carry large context including tokens such as Transaction Tokens [TRATS] (which assure the identity and context of each request), SPIFFE [SPIFFE] tokens (which assures the service identity) and possibly other context. The Contextualized REST (CREST) architecture adds a cached context to REST, with mechanisms to negotiate the establishment of the context when it is not found. Each request can refer to the context items it depends upon instead of carrying the entire context with the request. The server can accept the reference to the context item or respond with a specific error to prompt the client to reestablish the context. Clients can create new or delete existing context items in separate requests or as a part of other requests. The CREST architecture assumes the server holds the context across different requests in a server-side cache. Such a cache may be typically shared across various applications and services within a VPC or a data center. The possibility that subsequent requests from the same client will reach different VPCs or data centers is low, thus providing an efficiency optimization for the vast majority of requests. |
| | Bundle Protocol Regions for Network Scaling |
| |
|
This document describes a mechanism for assembling a delay-tolerant network of arbitrary size from discrete sets of nodes - "regions" - within which delay-tolerant routing based on contact plans is computationally tractable. |
| | E6Translate: Bridging IPv4-Only Hosts to IPv6 Internet |
| |
|
E6Translate (E6T) is a protocol designed to address the challenges of bidirectional communication between IPv4-only hosts and the IPv6 Internet. Leveraging the reserved Class E IPv4 address space (240.0.0.0/4) as temporary placeholders for IPv6 destinations, E6T provides a lightweight and scalable mechanism for IPv4-to-IPv6 mapping and vice versa. To enable reverse connectivity, E6T repurposes a /96 segment of a /64 IPv6 prefix for IPv4-equivalent mapping, facilitating port forwarding and external access to legacy devices. This document outlines the design, operation, and practical applications of E6T, along with considerations for security, deployment, and protocol standardization. |
| | Scalable Quality Extension for the Opus Codec |
| |
|
This document updates RFC6716 to add support for a scalable quality layer. |
| | Measurement Method for Bandwidth of SRv6 Forwarding Path |
| |
|
This document proposes a method for measuring the actual bandwidth of SRv6 forwarding paths. Carrying the bandwidth information from bottleneck nodes along the packet path in the IPv6 extension header of data packets or active measurement packets, the SRv6 headend node and controller can obtain the actual minimum available bandwidth of the forwarding path in real-time. |
| | IP Address Space for Outer Space |
| |
|
The exploration of outer space depends heavily upon communications technology and in many cases, uses IP. IP address allocation has been formally assigned to Regional Internet Registries (RIRs), but there is no formal allocation of address space for networks in outer space. This document describes updates existing address allocation procedures to include address space for outer space. |
| | Certificate Status Information Mechanism Description Updates to RFC 5280 |
| |
|
The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960]. |
| | Satellite Ground Routing Architecture Based on Access Satellite Prediction |
| |
|
With the development of network technology, the satellite network are gradually integrating with the terrestrial network. This draft illustrates a satellite ground routing architecture based on access satellite prediction to solve the end-to-end communication issue in the satellite ground integration scenario where the connection between terrestrial nodes and satellites switches frequently. This architecture includes registration nodes which are responsible for maintaining access node information. Each access node preserve satellite orbit information, performs access satellite prediction, and generates encapsulation addresses. The access satellite undertakes data encapsulation, data forwarding, and data unencapsulation based on encapsulation addresses. |
| | Problem Statement about IPv6 Support for Multiple Routers and Multiple Prefixes |
| |
|
This document discusses current limitations in IPv6 Stateless Address Auto-cofiguration (SLAAC) that prevent support for common multi- router and multi-interface scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. |
| | IPFIX Protocol over QUIC |
| |
|
The IP Flow Information Export (IPFIX) Protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Data and Template Records can be carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. The supported transport protocols are SCTP, UDP and TCP. QUIC could provide useful, reliable and secure semantics for IPFIX Protocol in particular as a single connection could carry multiple traffic flows over streams, enabling much better efficiency and performance for Exporter and Collector. This document describes how to use IPFIX Protocol over the QUIC transport protocol, named IPFIXoQUIC. |
| | Kemeleon Encodings |
| |
| | draft-veitch-kemeleon-00.txt |
| | Date: |
29/11/2024 |
| | Authors: |
Felix Guenther, Douglas Stebila, Shannon Veitch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies Kemeleon encoding algorithms for encoding ML- KEM public keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of public keys and ciphertexts, relying on module LWE assumptions. This document specifies a number of variants of these encodings, with differing failure rates, output sizes, and performance profiles. |
| | DKIM Access Control and Differential Changes |
| |
|
This document specifies a bundle of DKIM (RFC 6376) extensions and adjustments. They do not hinder the currently distributed processing environment that includes DKIM, ARC, DMARC and SPF, and are as such backward compatible. Their aim is however to ultimately slim down the email environment that needs to be administrated and maintained, by establishing mutual agreements in between sender and receiver(s), verifiable through public-key cryptography, and let the SMTP protocol handle decisions solely based upon that. |
| | SCONE Solution Analysis |
| |
| | draft-brw-scone-analysis-00.txt |
| | Date: |
02/12/2024 |
| | Authors: |
Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document provides an analysis of various SCONE solutions to share the throughput advice. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery. |
| | Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, multimedia content production and distributed training. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications. |
| | Technical guidelines of Web server certification path validation for Interent browser |
| |
|
In Web PKI, certificate path construction and validation are crucial security review processes. At present, there are many Internet browser manufacturers around the world. With the change of security practices and the development of technology, the certificate validation process in Internet browser industry is relatively messy, including various private implementations of manufacturers. It is a typical patching improvement method, and the implementation of process functions is relatively arbitrary. This document provides a technical guide for certification path validation of web server certificates during Internet SSL/TLS protocol communication for Web PKI, including the basic path verification process, as well as reference procedures, guidance and suggestions for input, initialization, and basic certificate processing in the verification process. This document is applicable to the development and application of Internet browsers, as well as other similar digital certificate authentication systems requiring SSL/TLS security protocol secure communication. |
| | CORECONF: Managing IoT Devices with YANG Models |
| |
|
This short paper provides an overview over the CORECONF architecture for employing YANG models in managing IoT devices. CORECONF is based on CoAP as a transfer protocol and YANG-CBOR as its data representation format, analogous to the way the original RESTCONF was defined to use HTTP and YANG-XML or YANG-JSON, and the way NETCONF uses SSH and YANG-XML. |
| | hardware divvying |
| |
|
a proposal for hardware divvying (specifically in the case of RAM) |
| | Client Conformance Signal for SCONE |
| |
|
This document proposes conformance signals to be sent by QUIC clients to indicate whether they are able to adapt to the bitrate indicated by the SCONE signal, so that communication service providers MAY stop policing. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | Problem Statement for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Network (HP-WAN) is designed for many applications such as scientific research, academia, education and other data-intensive applications which demand high-speed data transmission over WANs, and it needs to provide efficient transmission services within a completion time. This document outlines the problems for HP-WANs. |
| | Maximum Prefix Outbound Route Filter for BGP |
| |
|
This document introduces a Maximum Prefix ORF (Outbound Route Filtering) type for BGP. It aims to provide a mechanism whereby the sender of route information is informed of the maximum number of prefixes that the receiver is willing to accept. This facilitates improved resource management by limiting the number of routes exchanged, avoiding unnecessary or excessive route propagation, and reducing memory and CPU load. |
| | EUF-CMA for the Cryptographic Message Syntax (CMS) SignedData |
| |
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists a number of potential mitigations for LAMPS working group discussion. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. |
| | YANG deVELpment PrOCEss & maintenance (VELOCE) |
| |
|
This document describes a YANG deVELpment PrOCEss & maintenance (VELOCE) that is more suitable for the development of YANG modules within the IETF. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-boucadair-veloce-yang. |
| | Source Buffer Management |
| |
|
In the past decade there has been growing awareness about the harmful effects of bufferbloat in the network, and there has been good work on developments like L4S to address that problem. However, bufferbloat on the sender itself remains a significant additional problem, which has not received similar attention. This document offers techniques and guidance for host networking software to avoid network traffic suffering unnecessary delays caused by excessive buffering at the sender. These improvements are broadly applicable across all datagram and transport protocols (UDP, TCP, QUIC, etc.) on all operating systems. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extension for DSCP and ECN Traversal Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document defines a STAMP extension to enable the measurement of manipulation of the value of the explicit congestion notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field. |
| | Fast failure detection in VRRP with S-BFD |
| |
|
The Virtual Router Redundancy Protocol (VRRP) protocol depends on the availability of layer three (3) IPvX connectivity between redundant peers and it can interact with the variant of Seamless Bidirectional Forwarding Detection (S-BFD) protocol to achieve a much faster failure detection. This document describes how to extend the VRRP protocol to support S-BFD as a detection system for Primary Router failures. To announce the use of this implementation, a new VRRP packet type and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the S-BFD Discriminators is also implemented. |
| | Post-Quantum Guidance for TLS. |
| |
|
We provide guidance on the use of post-quantum algorithms for those deploying applications using TLS. |
| | Security and Privacy Considerations for Deep Space Network |
| |
|
Deep Space Network (DSN) inherits potential security vulnerabilities as well as privacy issues. This document describes various threats and security concerns related to Deep Space Networks and existing approaches to solve these threats. |
| | What is TCP? |
| |
|
This document references STD 7. |
| | Application State Components for More Instant Messaging Interoperability (MIMI) |
| |
|
This document presents structures for room metadata, participant lists, pre-authorized roles for future participants, and role-based access control, all of which are intended for use in MIMI (More Instant Messaging Interoperability). |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. |
| | OAuth Resource Helper |
| |
|
This Internet Draft introduces the concept of a Resource Helper in OAuth 2.0. A Resource Helper is a modular component that assists the Authorization Server in managing fine-grained authorization processes. The Resource Helper, associated with a specific Resource Server, handles scope selection and resource-specific details, providing the user-interface for the Resource Owner to approve or refine access requests. By offloading scope-related user interaction to the Resource Helper, the Authorization Server remains generic and stable while the Resource Helper evolves alongside the Resource Server's requirements. This specification defines the protocol, interfaces, and flow between the Authorization Server and the Resource Helper. Introducing a Resource Helper does not affect the OAuth client or the interaction between the OAuth client and the Resource Server. |
| | A Task Segmentation Framework for Computing-Aware Traffic Steering |
| |
|
This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the stepwise mode, providing detailed workflows for each. |
| | Trust is non-negotiable |
| |
|
This document considers proposals to enable the negotiation of trust anchors in TLS. It makes three basic arguments: that trust negotiation is not helpful in addressing the problems it claims to address, that trust negotiation instead comes with material harms to the critical trust infrastructure of the Internet, and that the proposed mechanisms for deploying trust negotiation are unworkable. This draft goes on to discuss simpler and more effective solutions to these problems. |
| | PCRP Webhook Specification |
| |
|
This document defines the PCRP (Ping, Challenge, Resolve, Product) Specification for Webhook events in a standardized way. It is specifically designed to address the challenges faced in current webhook event implementations, which lack consistency and a defined flow. PCRP introduces a new header X-PCRP-Type to indicate the step of the process, and its values include ping, challenge, resolve, and product. |
| | Next Generation browser |
| |
|
Next Generation browser |
| | Public Key Hash for Local Domains |
| |
|
This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake. |
| | SRv6 Group Based Policy |
| |
|
This document extends the Segment Routing over IPv6 (SRv6) Network Programming framework [RFC8986] by incorporating group-based policy capabilities. |
| | Enhancing Local-Use Domain Name Resolution within Link-Local Scope |
| |
| | draft-gong-mdns-local-00.txt |
| | Date: |
01/01/2025 |
| | Authors: |
LiangYi Gong, Zhiwei Yan, Man Zhang, Kejun Dong, Chun Long |
| | Working Group: |
Individual Submissions (none) |
|
Link-local networks such as home Internet of Things (IoT) and industrial Internet of Things are becoming increasingly prosperous, with a large number of small devices deployed in the link-local networks. These devices discover each other through ".local." domain names of DNS-based zero-configuration network protocol. However, the lack of specialized security operations to supervise link-local DNS resolution leads to some security risks. This memo addresses the potential risks associated with the leakage of link-local DNS traffic to external networks, the lack of identity authentication on ".local." domain requests, and the lack of rate-limiting on ".local." domain responses, which poses the leakage of link-local device information and the risk of DDoS attacks. Furthermore, the document proposes a set of best practices and technical solutions to mitigate these risks and ensure that ".local." domain name resolution remains confined within the local network segment. |
| | Distributed Micro Service Communication architecture based on Content Semantic |
| |
|
This draft introduces a novel communication architecture, called Distributed Micro Service Communication architecture (DMSC). It includes multiple aspects of microservice communication, such as service registration, service discovery, service routing, service scheduling, and more , Which to achieve all the essential functionalities provided by current centralized service networks. By incorporating content-semantic communication, DMSC significantly enhances the performance, scalability, and reliability of microservice communication. It provides a robust architecture for managing the complex communication requirements of distributed microservices, ensuring data integrity, security, and efficient resource utilization. Furthermore, DMSC provides a reference direction for the transition of the service mesh infrastructure from a location-based model to a content- and service-centric paradigm. |
| | Updates to SIPREC correcting Metadata Media Type |
| |
|
SIP-based Media Recording (SIPREC) protocol is defined by both RFC 7865 and RFC 7866. Unfortunately both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFCs registered the new media type. This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and registers the new media type. |
| | Problem Statements of Service Mesh Infrastructure and Requirements of DMSC |
| |
|
Service meshes, as one infrastructure, has been widely used in the major public cloud providers. Its main function is to accomplish the policy routing, precise traffic allocation, and traffic throttling etc. Currently, the design and implementation of service mesh takes the centralized control approach, which bring various challenges for its current deployments and further developments. This document analyzes the problems that exists in current service mesh implementations, and provide the requirements for the future distributed micro service communication(DMSC) infrastructure. |
| | A Referee to Authenticate Servers in Local Domains |
| |
|
Obtaining and maintaining PKI certificates for devices in a local domain network is difficult for both technical and human factors reasons. This document describes an alternative approach to securely identify and authenticate servers in the local domain using a HTTPS- based trust anchor system, called a Referee. The Referee allows bootstrapping a network of devices by trusting only the Referee trust anchor in the local domain. |
| | Current State of the Art for Routing in AI Networks |
| |
|
This document provides an overview of routing technologies that address the needs of traffic engineering and load balancing, with a focus on fast notification for example in adaptive routing. As the scale and complexity of networks grow, these technologies are becoming increasingly important when fault tolerance and rapid convergence are critical. The document explores existing solutions from both the IETF and the broader industry, highlighting their applicability to various use cases, including AI workloads and general services that demand low-latency fault recovery and dynamic load distribution across data center networks and inter data center. It also offers suggestions for potential IETF initiatives to further develop and standardize these techniques. |
| | Ascon-AEAD128 for JOSE and COSE |
| |
| | draft-ochkas-cose-ascon-01.txt |
| | Date: |
21/01/2025 |
| | Authors: |
Dmytro Ochkas, Helene Le Bouder, Alexander Pelov |
| | Working Group: |
Individual Submissions (none) |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations with Ascon which received a lot of attention in the area of lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption [asconv1.2-caesar]. After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography [asconv1.2-nist]. This recognition makes it particularly interesting to use Ascon with COSE and JOSE structures. This document does not define any new cryptography, only serializations of existing cryptographic systems described in [NIST.SP.800-232]. |
| | Out-of-order Insensitive Traffic In the Network |
| |
|
This document describes a kind of out-of-order insensitive traffic in the transport network, and the related load balancing mechanism for it. |
| | Hybrid Post-quantum Key Exchange SM2-MLKEM for TLSv1.3 |
| |
|
This document specifies how to form a hybrid key exchange with CurveSM2 and MLKEM in Transport Layer Security (TLS) protocol version 1.3. Related IETF drafts include [hybrid] and [ecdhe-mlkem]. |
| | A 3D Location Profile for the Location-to-Service Translation (LoST) Protocol |
| |
|
This document defines a new location profile containing three- dimensional (3D) shapes to be used with the Location-to-Service Translation Protocol (LoST) defined in RFC 5222. Registration of the 3D location profile in the "Location-to-Service Translation (LoST) Location Profiles" IANA registry is requested accordingly. Inconsistencies in RFC 5222 relating to additional location profiles are revised and additional clarification is given to assist implementors when using this profile. |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines Post-Quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| | Flooding Reduction Algorithms Interoperability Framework |
| |
|
This document introduces a framework that makes it possible to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. |
| | Technical Considerations for Distributed Micro Services Communication |
| |
|
With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, updated framework and architecture would be required and designed, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning with Distributed Micro Service Communication (DMSC). |
| | JSON Web Token Best Current Practices |
| |
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. |
| | RADIUS attributes for National Security and Emergency Preparedness Service |
| |
| | draft-gundavelli-radepcs-00.txt |
| | Date: |
15/01/2025 |
| | Authors: |
Sri Gundavelli, Subir Das, Mark Grayson, Martin Dolly, An Nguyen |
| | Working Group: |
Individual Submissions (none) |
|
This document describes RADIUS attributes for supporting authorization of Emergency Preparedness Communication Service (EPCS), enabling authorized users to benefit from preferential access to Wi- Fi network resources during congestion. |
| | Incrementally Deployable DNSSEC Delegation |
| |
|
This document proposes a DNSSEC delegation mechanism that complements [I-D.homburg-deleg-incremental-deleg]. In addition this mechanism simplifies multi-signer setups by removing the need to coordinate for signers during key rollovers. |
| | Media over QUIC - Use Cases |
| |
|
MoQ is designed to serve live tracks over a CDN to viewers with varying latency and quality targets: the entire spectrum between real-time and VOD. However, it's difficult to understand how to use the transport given the layering and complexity of live media delivery. This document outlines how an application could use MoQ to deliver video, audio, and metadata in a variety of scenarios. |
| | RFC Editor Model |
| |
|
RFC 9280 specifies version 3 of the RFC Editor Model. Since its publication, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. There is a repository for this draft at https://github.com/ paulehoffman/9280-updates (https://github.com/ paulehoffman/9280-updates). |
| | Vocabulary for Expressing Content Preferences for AI Training |
| |
|
This document proposes a vocabulary for expressing content preferences for rightsholders who wish to manage the use of their content in AI training. This vocabulary allows publishers to express preferences through metadata or content-delivery protocols. The vocabulary can be applied at different levels of granularity and incorporates preferences for permissions, usage scope, and data retention, providing a foundation for interoperability across various Internet protocols. |
| | RPC Roles and Responsibilities |
| |
|
This document updates RFC 9280 to specify that the RPC is responsible for operational decisions needed to implement RFC Series policies as they pertain to the document publication process code and tools, and provides a pathway for resolution of disagreements with those operational decisions. This document also updates RFC9280 to acknowledge that RFC Consumers, a distinct but partially overlapping group with IETF participants, must be specifically considered in the process of writing and implementing RFC Series policies, and makes the RPC responsible for representing their interests. Additionally, this document updates language in RFC7990, RFC7991, RFC7992, RFC7993, RFC7994, RFC7995, RFC7996, and RFC7997 to transfer responsibilities previously held by the RFC Editor or RFC Series Editor to the RPC. |
| | Documenting and Referencing Cryptographic Components in IETF Documents |
| |
|
This document describes the history of how cryptographic components have been documented and referenced in the IETF, particularly in RFCs. It also gives guidance for how such specification should happen in the future. %% (To be removed before publication as an RFC) This document is being developed in SAAG. There is a git repo for the document at https://github.com/paulehoffman/draft-paulwh-crypto-components (https://github.com/paulehoffman/draft-paulwh-crypto-components). %% |
| | DNS Account Handles,A Whitepaper |
| |
|
A proposal for use of DNS names to support universal account identifiers 'handles' is described. Once registered, a handle may be used for authentication to any network service, to initiate communication with the holder or as the basis for IoT device management. This document is a whitepaper proposing the general approach. A strawman prototype supporting single account Web login across multiple sites, onboarding of IoT devices and end to end secure messaging, file-drop, voice and video and has been built using existing and proposed IETF work. |
| | AES-GMAC for COSE |
| |
|
This document registers COSE algorithm code points for using the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a Message Authentication Code (AES-GMAC). The security strength provided by these registrations is identical to existing COSE registrations for AES-GCM authenticated encryption. |
| | Options representation in SCHC YANG Data Models |
| |
|
The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol. |
| | Introducing `s://` as a Secure URL Scheme to replace `https://` |
| |
|
This document proposes the introduction of `s://` as a universal shorthand for secure URLs, replacing the explicit use of `https://`. The proposed scheme simplifies URL syntax, assumes secure connections by default, and aligns with the modern web's security-first approach. The adoption of `s://` is expected to enhance user experience, improve efficiency, and reinforce secure practices across the internet. |
| | HTTP Streaming: Standard for Age-Appropriate Video Content Guidelines (VCG) and Delivery |
| |
|
The delivery of inappropriate video content for OTT and Social Media with HTTP video streaming is a serious worldwide problem. Most of the countries have established age-related and parental guidelines to warn about inappropriate or unintended content, particularly for children. However, these guidelines do not offer the freedom or convenience for audiences to avoid consumption of inappropriate content for their target age group instead just provide warning messages only.The Age-Relevant Video Content Guidelines (VCG) Standard defines a standard meta data format which covers fully and partially scene by scene age relevancy meta data for video and audio content and hence establishes a mechanism for delivering video and audio content tailored to the viewers' age groups. The Video Content Guidelines(VCG) is a meta data file which can enable existing HTTP based adaptive streaming standard like HLS, DASH, CMAF, MSS and HDS with updating manifest file using VCG meta data, that ensures only the target age-appropriate content is delivered to the audience and in-appropriate data can be skipped or modified so that different age group audience can choose what they want to watch. This ensures the compatibility of with the standard adaptive streaming protocols and players, so that the existing social Media and OTT streaming infrastructure continue to work without any major changes. |
| | Use Cases for Energy Efficiency Management |
| |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-use-cases |
| | The IMAP WEBPUSH extension |
| |
|
This document defines a WEBPUSH extension of the Internet Message Access Protocol (IMAP) that permits IMAP servers to send WebPush notifications. |
| | Architecture of Content-Based Service Router |
| |
|
This document first describes an architecture of Content-based Service Router (CSR), which is used to exchange service prefixes and topology information based on distributed routing protocol, and optimize routing based on service prefixes and topology, as one important component of Distributed Micro Service Communication (DMSC) architecture. |
| | DNS Update with JSON |
| |
|
It is common for service providers such as certificate authorities and social media providers to want users to update the users' zones to prove that they control those zones, or to add other features. Currently, service providers tell users to do this using human language describing the resource record type and data values to enter into the zone. This document describes a text format, called "DNS update with JSON" or "DUJ", for such a service provider to give to a user, with the expectation that the user would copy and paste the text to their DNS operator to update the user's zone. DNS operators who know how to handle DUJ strings will make the update process easier and more predictable for their users. |
| | Video Session Data Rate for SCONE protocol |
| |
|
The SCONE protocol requires a semantically consistent way for CSPs to convey a throughput advice. The Video Session Data Rate (VSDR) describes the formula to be applied both for setting the limit on the CAP side as well as for the CSP to validate conformance with the policy. |
| | Distributed AI model architecture for microservices communication and computing power scheduling |
| |
|
This document describes the distributed AI micromodel computing power scheduling service architecture. |
| | Scalable Name-Based Packet Forwarding |
| |
|
This document specifies a scalable approach to name-based packet forwarding, a fundamental component of content semantic network architectures. Unlike IP-based forwarding, name-based forwarding must address the challenges of handling variable-length, unbounded keys and significantly larger namespaces. The proposed approach leverages two key insights to enable scalable forwarding for billions of prefixes. First, by representing names as binary strings, forwarding tables with millions of entries can be effectively compressed using Patricia tries to fit within contemporary line card memory. Second, the data structure is designed and optimized to ensure its size is dependent only on the number of rules, not the length of the rules themselves. |
| | Dynamic Trust Security Architecture for Distributed Service Mesh |
| |
|
This document proposes a Service Mesh Dynamic-Trust Architecture (SM- DTA) to address security risks in dynamic service-to-service communication within distributed service mesh environments. The architecture is applicable to scenarios such as elastic service scaling and cross-domain service invocation. SM-DTA enforces end-to- end security governance through service identity authentication, dynamic context-aware policy engines, and data sovereignty proxies. |
| | SASL Passkey |
| |
|
Introduces a SASL mechanism that allows the user to authenticate using a FIDO2 Passkey. |
| | IKEv2 Support of ML-DSA |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. NIST has recently standardized ML-DSA, which is a signature algorithm believed to be secure against Quantum Computers. This document describes how to use ML-DSA with IKEv2 as an auhentication scheme. |
| | Improving Support for Multi-Router and Multi-Prefix IPv6 Networks |
| |
|
This document specifies a improvements to IPv6 Stateless Address Autoncofiguration (SLAAC) to fully support common multi-router and multi-prefix scenarios. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8504, and obsoletes RFC 8028, such that these scenarios are properly supported by IPv6 host implementations. |
| | Enhanced JWE Security with Detached Additional Authenticated Data (AAD) |
| |
|
This draft introduces a mechanism to support detached Additional Authenticated Data (AAD) in JWE (JSON Web Encryption), allowing the AAD to be derived from context-specific information, such as session identifiers, algorithm identifiers, and identifiers of communication endpoints, rather than being transmitted in-band. This mechanism strengthens security by mitigating risk against unknown-key-share attacks and/or other exploitation techniques that depend on some type of confusion over the role played by each party. The document explains how to integrate this functionality into JWE, covering both JWE JSON Serialization and JWE Compact Serialization. |
| | GREASE Code Points in OpenPGP |
| |
|
This document reserves code points in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS. |
| | WIMSE Credential Exchange |
| |
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. |
| | Stateless Hash-Based Signatures for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of Sphincs+/SLH-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | SCHC Rule Format for Message Aggregation in Delay Tolerant Networks |
| |
|
This document defines a new Rule Format for Message Aggregation (referred to as Aggregation) within the SCHC framework. By bundling multiple SCHC-compressed packets into a single Aggregation Data Unit (ADU), the mechanism reduces the number of transmissions required in delay-tolerant networks. The Aggregation process is triggered by conditions such as reaching the L2 Maximum Transmission Unit (MTU), exceeding a maximum delay, or meeting a minimum packet rate threshold. This new rule type is backward compatible with existing SCHC operations and offers an efficient solution for energy-sensitive and asymmetric communication scenarios. |
| | SCHC Rule Format for Reliability Fragmentation in Constrained Networks |
| |
|
This document specifies a new Rule Format for Reliability Fragmentation within the SCHC framework. Building on the fragmentation mechanisms defined in RFC8724, this rule format is tailored to ensure the reliable delivery of small messages that do not trigger conventional fragmentation. A key enhancement is the inclusion of a size field, indicating the total byte-length of the message, and modifications to the state machine to support a persistent session with wrap-around windows. Two operational modes are defined: * RelNoAck: A mode derived from SCHC No-Ack fragmentation, where fragments are transmitted continuously without expecting per- fragment acknowledgments. Losses are tolerated within a configured threshold. * RelAckOnErr: A mode derived from SCHC Ack-On-Error fragmentation, where the receiver actively monitors for missing fragments and initiates recovery through explicit negative acknowledgments. These modes offer operators the flexibility to balance recovery overhead against latency and reliability requirements in constrained network environments. |
| | SCHC Architecture for Process Stacking and Routing in Constrained Networks |
| |
|
This document specifies architectural guidelines for dynamically stacking and routing SCHC processes in constrained networks. It details how independent SCHC modules can be composed into processing chains that adapt to PDU attributes. For instance, SCHC Compression may trigger SCHC Fragmentation when the compressed PDU exceeds the L2 MTU, or alternatively, trigger SCHC Aggregation. For traffic that is not delay tolerant, a direct routing from SCHC Compression to SCHC Reliability Fragmentation is provided. Subsequent processing by SCHC FEC Fragmentation modules ensures robust error correction. This modular approach promotes scalability and flexibility within the SCHC framework. |
| | A comparative analysis of SCONE relative to TRAIN |
| |
|
A merge of the rate availability signaling schemes in the SCONE and TRAIN proposals is analysed and found to be infeasible. |
| | Lightweight Directory Access Protocol (LDAP): Additional Syntaxes |
| |
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes. |
| | rLEDBAT for QUIC |
| |
|
This document specifies rLEDBAT for QUIC, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for QUIC at the receiver end. This draft explores adaptation strategies for integrating rLEDBAT with QUIC's framework, aiming to maintain compatibility with QUIC. |
| | Anonymous Rate-Limited Credentials |
| |
| | draft-yun-cfrg-arc-00.txt |
| | Date: |
05/02/2025 |
| | Authors: |
Cathie Yun, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. |
| | Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. |
| | SVGs in RFCs |
| |
| | draft-rossi-svgsinrfcs-01.txt |
| | Date: |
13/02/2025 |
| | Authors: |
Alexis Rossi, Nevil Brownlee, Jean Mahoney, Martin Thomson |
| | Working Group: |
Individual Submissions (none) |
|
This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from [RFC7996] and removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs. |
| | Distributed DNSSEC Multi-Signer Bootstrap |
| |
|
This document presents an architecture for a distributed DNSSEC multi-signer model that most closely resembles "model 2" in [RFC8901]. It defines two multi-signer specific entities: the "multi-signer agent" (MSA) that is responsible for the multi-signer process and the "combiner", which is responsible for "combining" unsigned zone data from the zone owner with zone data under control of the MSA. It introduces a new DNS RRtype, HSYNC, that is used by the zone owner to designate the chosen DNS Providers (signing and/or serving the zone). Furthermore it describes a mechanism for the MSAs to establish secure communication with each other, either via “pure DNS” communication secured by DNS SIG(0) signatures on each message or via a RESTful API secured by TLS. Finally, the document describes two models for multi-signer process synchronization: “leader/follower mode” and “peer mode” and the mechanism by which a set of MSAs decide which model to use for a given zone. The scope of the document is only the distributed aspect of DNSSEC multi-signer up to the point where secure communication and synchronization method between MSAs has been established. The “multi-signer algorithms” that deal with the actual synchronization required for multi-signer operation are described in [I-D.draft-ietf-dnsop-dnssec-automation]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer (https://github.com/johanix/draft-leon-dnsop-distributed-multi- signer). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Lightweight Secure Shell (SSH) Signature Format |
| |
|
This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. |
| | Hypertext Command Line Interface |
| |
|
This document proposes a codification of resources and their relations with hyperlinks, using Unix-like command line interface (CLI) semantics, to foster the creation of a reusable and prolific intersection between the REST architectural style and the pipe and filter style. |
| | SDP Offer/Answer for RTP over QUIC (RoQ) |
| |
|
This document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These new values are necessary to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. This document also contains non-normative guidance for implementers. |
| | A Method for Generating Semantically Opaque IPv6 Interface Identifiers (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
|
This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration (SLAAC). |
| | Bidirectional Metric based Shortest Path First Mechanism |
| |
|
This document describes the mechanism that can be used to accomplish the Shortest Path First(SPF) calculation within network based on the bidirectional metrics of the links. |
| | Quic Logging for Convergence of Congestion Control from Retained State |
| |
|
This document specifies a logging format for a cautious method for Careful Resume when using the IETF quic transport protocol. It defines the logging format for qlog. |
| | User Attributes in OpenPGP |
| |
|
This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. |
| | Evidence Transformations |
| |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester. Before a Verifier can appraise Evidence it may require transformation to an internal representation. This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation. |
| | Privacy Pass Reverse Flow |
| |
|
This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a reverse flow from the Origin to the Client/Attester/Issuer. It describes a way for redeeming Origins to perform new issuances in the same request. |
| | Recommendations for Key Directories over HTTP |
| |
|
This document defines recommendations for protocols that expose public keys over HTTP. |
| | IMAP REMEMBERME extension for quick reauthentication token generation |
| |
|
This document specifies an IMAP extension for generating quick reauthentication tokens that allow clients to re-login without user interaction, once authentication using a strong SASL mechanism is completed. |
| | The Multicast Application Port |
| |
|
This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. |
| | Short Usage Preference Strings for Automated Processing |
| |
|
Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines a very simple format for expressions. This document updates RFC 9309 to define one means of conveyance. An HTTP header field is also defined. |
| | Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol |
| |
|
This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements. |
| | IETF Meeting Network Recommendations |
| |
|
IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion. |
| | Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF |
| |
|
This draft proposes a new intra-domain Source Address Validation (SAV) solution. This solution leverages the Bidirectional Metric- based Shortest Path First (BM-SPF) mechanism to avoid the complexity introduced by asymmetric routing for source address validation. It allows intra-domain routers to generate directly the SAV rule from the router's FIB table, based on the reality that the source and destination interface will be same if the IGP domain is symmetric assured. |
| | Export of Path Segment Identifier Information in IPFIX |
| |
|
This document introduces a new IPFIX Information Element to identify the Path Segment Identifier(PSID) in the SRH for SRv6 path identification purpose. |
| | Dynamic Overlay Load Balancing |
| |
|
This document specifies a mechanism for an overlay service ingress PE to dynamically load-balance traffic to Multi-Homing PEs based on near real-time access link information advertised by those PEs. |
| | COSE Algorithms for Two-Party Signing |
| |
|
This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited- bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data. |
| | Synchronized Video-on-Demand (VoD) Viewing with Media over QUIC Transport |
| |
|
This draft presents an approach for synchronized video-on-demand (VoD) viewing with Media over QUIC Transport (MOQT). It extends the current MOQT protocol to enable synchronized VoD functionality. This approach adapts MOQ’s push-content architecture to include interactive features such as pause, resume and seek. |
| | In Situ Operations,Administration,and Maintenance (IOAM) Active Measurement for Multi-path |
| |
|
Active measurements are typically used to collect the information of a specific path. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which promotes the information collection and topology restoration of a multi-path topology. It can help the operators to know the performance of network comprehensively and efficiently. |
| | A Profile for Forwarding Commitments (FCs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Forwarding Commitments (FCs) objects used in Resource Public Key Infrastructure (RPKI). An FC is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an FC's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. |
| | BGP AS_PATH Verification Based on Forwarding Commitment (FC) Objects |
| |
|
The Forwarding Commitment (FC) is an RPKI object that attests to the complete routing intents description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an FC-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that FC can help address and provides operational considerations associated with FC deployment. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. |
| | QUIC Profile for Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. In this context, typical QUIC stacks default transport parameters for terrestrial Internet are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case and guidance to QUIC stack developers to properly expose the required transport parameters in their API. |
| | Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
| |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| | Forward and Reverse HTTP/3 over WebTransport |
| |
|
HTTP/3 was initially specified only for use with the QUIC version 1 transport protocol. This specification defines how to use HTTP/3 over a WebTransport session, which can be implemented using any WebTransport protocol. This enables operation of HTTP/3 when UDP based transport is not available, as well as server-initiated HTTP/3 requests. |
| | Standardized Query Name for DNS Resolver Reachability Probes |
| |
|
This specification standardizes DNS names that should be used for checking connectivity to a DNS server. 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-sst-dnsop-probe-name/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/probe-name. |
| | Anomalous Packets Handling for DetNet |
| |
|
In deterministic networking (DetNet), there may be resource conflicts at the flow aggregation nodes, resulting in network anomalies. The existing mechanisms for handling anomalous packets in the data plane are crude, such as discarding or processing them as BE flows, so the network performance may be worse than applying traditional QoS. Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an anomalous packet handling solution for anomalous traffic in DetNet. This solution includes two policies: the packet squeezing policy and the packet degrading policy, which can be applied flexibly to a variety of queuing mechanisms, thereby ensuring that network traffic for deterministic services is preferentially scheduled in anomalous situations. |
| | High Performance Wide Area Network (HPWAN) Use Cases and Requirements -- From Public Operator's View |
| |
|
Bulk data transfer is a long-lived service over the past twenty years. High Performance Wide Area Networks (HP-WANs) are the backbone of global network infrastructure, enabling the seamless transfer of vast amounts of data and supporting advanced scientific collaborations worldwide. Many of the state-of-the-art dedicated networks have been mentioned in [I-D.kcrh-hpwan-state-of-art]. For non-dedicated networks like public operator's network, the case is different in terms of QoS policies, security policies, etc. This document presents use cases and requirements of HPWAN from public operator's view. |
| | Use of Variable-Length Output Preudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of variable-length output Preudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFCs 5723, 6617, 6631, 7296, 8784, 9370 for the cases when variable-length output Preudo-Random Functions are used in IKEv2 and its extensions. |
| | Advertisement of SR Policy Administative Flags using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | IPv6 Checksum Option |
| |
|
This document specifies a Checksum Option for IPv6. This is a Destination Option that allows a checksum to be computed over a variable number of bytes in the packet. The option allows the ICMPv6 checksum to be optional, and the UDPv6 checksum to be generally optional. |
| | Date and Time on the Internet: Durations |
| |
|
This document specifies a syntax for representing time durations; the syntax is a subset of that specified by ISO 8601. |
| | QUIC network awareness Acknowledgements |
| |
|
This document defines a quic ACK frame format for notifying network status information. |
| | Registry scoped members for RPSL set objects |
| |
|
This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information which contained QUIC Header, QUIC Frame and Stream that traffic is being forwarded with. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing SMTP related registries need to be restructured and existing entries need to be updated. This document describes these tasks. |
| | Eligibility Concept in Segment Routing Policies |
| |
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. |
| | Lightweight Authentication Methods for IP Header |
| |
|
This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. |
| | IP in Deep Space: Key Characteristics,Use Cases and Requirements |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. |
| | Critical-CH for Client Hint Reliability |
| |
|
This document defines the Critical-CH HTTP response header to allow HTTP servers to reliably specify their Client Hint preferences. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Tanych/http-client-hint-reliability. |
| | Client Hint Reliability ACCEPT_CH Frame |
| |
|
This document defines the ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably specify their Client Hint preferences. It aims to improve the performance to deliver Client Hint. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Tanych/http-client-hint-reliability. |