| draft-aaron-acme-profiles-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-abraitis-bgp-version-capability-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-abraitis-idr-addpath-paths-limit-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-abraitis-idr-maximum-prefix-orf-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-accilent-at-sign-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-acee-idr-lldp-peer-discovery-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-acee-rtgwg-vrrp-rfc8347bis-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-acme-device-attest-03.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Device Attestation Extension | ||||||||||||||
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. | |||||||||||||
| draft-adams-bimi-reporting-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-aft-ai-traffic-00.txt | ||||||||||||||
| Handling inter-DC/Edge AI-related network traffic: Problem statement | ||||||||||||||
|
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. | |||||||||||||
| draft-aft-detnet-bound-delay-queue-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-agrawal-bess-bgp-srv6-mpls-interworking-01.txt | ||||||||||||||
| BGP extensions for SRv6 and MPLS interworking | ||||||||||||||
|
This document define the BGP protocol extensions required to provide interworking between SRv6 and SR-MPLS/MPLS for SRv6 deployment. | |||||||||||||
| draft-akiyama-cmg-00.txt | ||||||||||||||
| Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing | ||||||||||||||
|
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. | |||||||||||||
| draft-albanna-regext-rdap-deleg-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ali-idr-srv6-policy-sid-list-optimization-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ali-pce-srv6-policy-sid-list-optimization-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-alvestrand-avtcore-abs-capture-time-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-cbor-packed-by-reference-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-cbor-packed-shuffle-00.txt | ||||||||||||||
| Packed CBOR: Table permutations | ||||||||||||||
|
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 altering configured tables to optimize the use of efficient encoding points by shuffling around entries in the packing tables. | |||||||||||||
| draft-amsuess-core-cachable-oscore-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-core-coap-kitchensink-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-core-coap-over-gatt-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-core-resource-directory-extensions-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-core-stateless-oscore-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-lake-edhoc-grease-01.txt | ||||||||||||||
| Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility | ||||||||||||||
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. | |||||||||||||
| draft-amsuess-t2trg-onion-coap-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-amsuess-t2trg-raytime-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-andersson-mpls-rfc8029-lsp-ping-naming-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-andersson-netconf-quic-client-server-02.txt | ||||||||||||||
| YANG Groupings for QUIC clients and QUIC servers | ||||||||||||||
|
This document defines three YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers. Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server | |||||||||||||
| draft-andrews-dnsop-pd-reverse-03.txt | ||||||||||||||
| Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation | ||||||||||||||
|
This document describes a method to automate the delegation of IP6.ARPA reverse zones when performing Prefix Delegations. | |||||||||||||
| draft-andrews-private-ds-digest-types-00.txt | ||||||||||||||
| Private DS Digest Types | ||||||||||||||
|
When DS records where defined the ability to fully identify the DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked. This documents specifies 2 DS Algorithm Types which allow the DNSSEC algorithm sub type to be encoded in the DS record. | |||||||||||||
| draft-annevk-johannhof-httpbis-cookies-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-antony-ipsecme-encrypted-esp-ping-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-antony-ipsecme-iekv2-beet-mode-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ar-emu-pqc-eapaka-02.txt | ||||||||||||||
| 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 making it quantum-safe. | |||||||||||||
| draft-arends-parent-only-record-signalling-00.txt | ||||||||||||||
| DNS Delegation Extensions | ||||||||||||||
|
New RR types have been proposed that appear only at the parent side of a delegation, similar to the DS resource record (RR) type. Supporting parent side RR types requires modifications to the DNS Security Extensions (DNSSEC). Without these modifications, validating resolvers are susceptible to response modification attacks. An on-path adversary could potentially remove the parent-side resource records without being detected. To detect the removal of a parent-side RR type, an authenticated denial record (such as NSEC or NSEC3) is necessary to confirm presence or absence of a parent-side RR type. Currently, validating resolver do not expect authenticated denial records in a secure delegation response. Therefore, a secure signal is needed to inform the validating resolver to anticipate authenticated denial records for a delegation. To support the future deployment of parent-side RR types, this draft designates a range of yet unallocated RR types specifically for parent-side use. Authoritative servers will include these records in a delegation response without requiring upgrades. | |||||||||||||
| draft-asai-tsvwg-transport-review-05.txt | ||||||||||||||
| Separation of Data Path and Data Flow Sublayers in the Transport Layer | ||||||||||||||
|
This document reviews the architectural design of the transport layer. In particular, this document proposes to separate the transport layer into two sublayers; the data path and the data flow layers. The data path layer provides functionality on the data path, such as connection handling, path quality and trajectory monitoring, waypoint management, and congestion control for the data path resource management. The data flow layer provides additional functionality upon the data path layer, such as flow control for the receive buffer management, retransmission for reliable data delivery, and transport layer security. The data path layer multiplexes multiple data flow layer protocols and provides data path information to the data flow layer to control data transmissions, such as prioritization and inverse multiplexing for multipath protocols. | |||||||||||||
| draft-atkinson-teas-rsvp-auth-v2-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-augustyn-intarea-ipref-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-aumasson-blake3-00.txt | ||||||||||||||
| The BLAKE3 Hashing Framework | ||||||||||||||
|
This document specifies the cryptographic hashing primitive BLAKE3, a secure algorithm designed to be fast and highly parallelizable. Apart from the standard hashing functionality, BLAKE3 can serve to realize the following cryptographic functionalities: extendable- output function (XOF), key derivation function (KDF), pseudo-random function (PRF), and message authentication code (MAC). | |||||||||||||
| draft-avrilionis-satp-asset-profiles-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-avrilionis-satp-asset-schema-architecture-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-avrilionis-satp-setup-stage-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-barguil-teas-network-slices-instantation-11.txt | ||||||||||||||
| Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management | ||||||||||||||
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. | |||||||||||||
| draft-barnes-mls-appsync-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-barnes-mls-replace-00.txt | ||||||||||||||
| The MLS Replace Proposal | ||||||||||||||
|
Post-compromise security is one of the core security guarantees provided by the Messaging Layer Security (MLS) protocol. MLS provides post-compromise security for a member when the member's leaf node in the MLS ratchet tree is updated, either by that member sending a Commit message, or by an Update proposal from that member being committed. Unfortunately, Update proposals can only be committed in the epoch in which they are sent, leading to missed opportunities for post-compromise security. This document defines a Replace proposal that allows the fresh leaf node in an Update proposal to be applied in a future epoch, thus enabling post- compromise security for the affected member even if their Update proposal is received too late to be committed. | |||||||||||||
| draft-barnes-oauth-pika-01.txt | ||||||||||||||
| Proof of Issuer Key Authority (PIKA) | ||||||||||||||
|
A relying party verifying a JSON Web Token (JWT) needs to verify that the public key used to verify the signature legitimately represents the issuer represented in the "iss" claim of the JWT. Today, relying parties commonly use the "iss" claim to fetch a set of authorized signing keys over HTTPS, relying on the security of HTTPS to establish the authority of the downloaded keys for that issuer. The ephemerality of this proof of authority makes it unsuitable for use cases where a JWT might need to be verified for some time. In this document, we define a format for Proofs of Issuer Key Authority, which establish the authority of a key using a signed object instead of an HTTPS connection. | |||||||||||||
| draft-barth-teas-yang-pg-aware-topo-00.txt | ||||||||||||||
| YANG Data Model for Power-Group Aware TE Topology | ||||||||||||||
|
This document discusses the notion of a Power-Group construct as an attribute of a Traffic Engineered (TE) Link and defines a YANG data model for representing a Power-Group aware TE topology. | |||||||||||||
| draft-bashandy-rtgwg-segment-routing-uloop-17.txt | ||||||||||||||
| Loop avoidance using Segment Routing | ||||||||||||||
|
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. | |||||||||||||
| draft-bastian-dvs-jose-01.txt | ||||||||||||||
| Designated Verifier Signatures for JOSE | ||||||||||||||
|
This specification defines designated verifier signatures for JOSE and defines algorithms that use a combination of key agreement and MACs. | |||||||||||||
| draft-bastian-jose-dvs-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bclp-green-terminology-00.txt | ||||||||||||||
| Terminology for Energy Efficiency Network Management | ||||||||||||||
|
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. | |||||||||||||
| draft-beck-tls-trust-anchor-ids-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-becker-cnsa2-tls-profile-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-belchior-satp-gateway-recovery-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-bernardos-cats-anchoring-service-mobility-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-cats-ip-address-anchoring-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-joint-selection-raw-mec-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-mec-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-mobility-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-multidomain-03.txt | ||||||||||||||
| RAW multidomain extensions | ||||||||||||||
|
This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. | |||||||||||||
| draft-berra-dnsop-keystate-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bft-rats-kat-05.txt | ||||||||||||||
| An EAT-based Key Attestation Token | ||||||||||||||
|
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. | |||||||||||||
| draft-bgp-ext-communities-map-prefixes-00.txt | ||||||||||||||
| Dynamic Prefix Configuration of MAP-T and MAP-E Parameters via BGP | ||||||||||||||
|
This document proposes an extension to the current MAP-T (Mapping of Address and Port using Translation) [RFC7599] and MAP-E (Mapping of Address and Port with Encapsulation) [RFC7597] configuration mechanisms. It allows for dynamically learned and programmed MAP-T or MAP-E prefix value parameters via BGP-learned prefixes marked with extended community attributes, enabling a more flexible and scalable approach compared to static configuration. | |||||||||||||
| draft-bgp-softwire-map-prefix-communities-00.txt | ||||||||||||||
| Dynamic Softwire Configuration of MAP-T and MAP-E Prefix Parameters via BGP | ||||||||||||||
|
This document proposes an OPTIONAL extension to the current MAP-T (Mapping of Address and Port using Translation) [RFC7599] and MAP-E (Mapping of Address and Port with Encapsulation) [RFC7597] configuration mechanisms. It allows for dynamically learned and programmed MAP-T or MAP-E prefix value parameters via BGP-learned prefixes marked with extended community attributes, enabling a more flexible and scalable approach compared to static configuration. | |||||||||||||
| draft-bi-intarea-savi-wlan-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bichot-delivery-metadata-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bichot-msync-17.txt | ||||||||||||||
| MSYNC | ||||||||||||||
|
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. | |||||||||||||
| draft-birgelee-lamps-caa-security-00.txt | ||||||||||||||
| CAA Security Tag for Cryptographic Domain Validation | ||||||||||||||
|
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. | |||||||||||||
| draft-birkholz-cose-receipts-ccf-profile-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-blanchet-dtn-bp-yang-model-02.txt | ||||||||||||||
| Bundle Protocol YANG Data Model | ||||||||||||||
|
This document describes the YANG model for the Bundle protocol. | |||||||||||||
| draft-blanchet-dtn-email-over-bp-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-blanchet-dtn-http-over-bp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-blanchet-tvr-contactplan-02.txt | ||||||||||||||
| Contact Plan YANG Model for Time-Variant Routing of the Bundle Protocol | ||||||||||||||
|
Some networks, such as in space, have links that are up and down based on a known schedule. The links characteristics, such as latency and bandwidth, are often also known in advance and are important information for routing decisions. This document describes a YANG data model, also known as contact plan. This specification applies to the Bundle Protocol. | |||||||||||||
| draft-bless-rtgwg-kira-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bmw-tls-pake13-00.txt | ||||||||||||||
| A Password Authenticated Key Exchange Extension for TLS 1.3 | ||||||||||||||
|
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. | |||||||||||||
| draft-bogdanovic-green-energy-metrics-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-bonica-gendispatch-exp-03.txt | ||||||||||||||
| IETF Experiments | ||||||||||||||
|
This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. | |||||||||||||
| draft-bonica-intarea-icmp-exten-hdr-len-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bonica-intarea-icmp-op-exp-00.txt | ||||||||||||||
| Internet Control Message Protocol (ICMP): Standards and Operational Experience | ||||||||||||||
|
The Internet Control Message Protocol (ICMP) can be used to exchange control information between hosts. This document summarizes ICMP standards and operational experience. The purpose of this document is to be used as a reference. A document that mentions ICMP can reference this document rather than repeating portions of its content. | |||||||||||||
| draft-bonica-spring-srv6-end-dtm-12.txt | ||||||||||||||
| SR-MPLS / SRv6 Transport Interworking | ||||||||||||||
|
This document describes procedures for interworking between an SR- MPLS transit domain and an SRv6 transit domain. Each domain contains Provider Edge (PE) and Provider (P) routers. Area Border Routers (ABR) provide connectivity between domains. The procedures described in this document require the ABR to carry a route to each PE router. However, they do not required the ABR to carry service (i.e., customer) routes. In that respect, these procedures resemble L3VPN Interprovider Option C. Procedures described in this document support interworking for global IPv4 and IPv6 service prefixes. They do not support interworking for VPN services prefixes where the SR-MPLS domain uses MPLS service labels. | |||||||||||||
| draft-bonnell-lamps-chameleon-certs-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-asdf-sdf-compact-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-asdf-sdf-mapping-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-asdf-sdftype-link-04.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-bormann-cbor-cddl-2-draft-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-cbor-cddl-freezer-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-cbor-det-03.txt | ||||||||||||||
| CBOR: On Deterministic Encoding | ||||||||||||||
|
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. | |||||||||||||
| draft-bormann-cbor-draft-numbers-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-cbor-notable-tags-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-cbor-numbers-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-cbor-rfc-cddl-models-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-core-responses-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-dispatch-modern-network-unicode-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-gendispatch-with-expert-review-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-nemops-coreconf-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-restatement-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-t2trg-deref-id-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bormann-what-is-tcp-00.txt | ||||||||||||||
| What is TCP? | ||||||||||||||
|
This document references STD 7. | |||||||||||||
| draft-bortzmeyer-add-resinfo-dnssecval-dns64-01.txt | ||||||||||||||
| 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". | |||||||||||||
| draft-bortzmeyer-more-edes-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-boucadair-netconf-port-numbers-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-boucadair-nmop-rfc3535-20years-later-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-boucadair-tcpm-rst-diagnostic-payload-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-boucadair-teas-ietf-slicing-overview-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-boucadair-veloce-yang-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bourbaki-6man-classless-ipv6-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bradleylundberg-cfrg-arkg-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brand-indicators-for-message-identification-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bray-unichars-10.txt | ||||||||||||||
| Unicode Character Repertoire Subsets | ||||||||||||||
|
This document discusses specifying subsets of the Unicode character repertoire for use in protocols and data formats. It also specifies those subsets as PRECIS profiles. | |||||||||||||
| draft-briscoe-docsis-q-protection-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-briscoe-iccrg-prague-congestion-control-04.txt | ||||||||||||||
| Prague Congestion Control | ||||||||||||||
|
This specification defines the Prague congestion control scheme, which is derived from DCTCP and adapted for Internet traffic by implementing the Prague L4S requirements. Over paths with L4S support at the bottleneck, it adapts the DCTCP mechanisms to achieve consistently low latency and full throughput. It is defined independently of any particular transport protocol or operating system, but notes are added that highlight issues specific to certain transports and OSs. It is mainly based on experience with the reference Linux implementation of TCP Prague and the Apple implementation over QUIC, but it includes experience from other implementations where available. The implementation does not satisfy all the Prague requirements (yet) and the IETF might decide that certain requirements need to be relaxed as an outcome of the process of trying to satisfy them all. Future plans that have typically only been implemented as proof-of- concept code are outlined in a separate section. | |||||||||||||
| draft-brossard-alfa-authz-00.txt | ||||||||||||||
| ALFA 2.0 - the Abbreviated Language for Authorization | ||||||||||||||
|
The Abbreviated Language for Authorization 2.0 is a constrained policy language aimed at solving fine-grained authorization challenges. This specification builds on top of [XACML] and replaces [ALFA] to provide a more complete and easier language to use. Use cases for ALFA 2.0 include the ability to express: - Role-based access control ([RBAC]), - Attribute-based access control ([ABAC]), and - Relationship-based access control ([ReBAC]) | |||||||||||||
| draft-brossard-oauth-rar-authzen-03.txt | ||||||||||||||
| AuthZEN Request/Response Profile for OAuth 2.0 Rich Authorization Requests | ||||||||||||||
|
This specification defines a profile of OAuth 2.0 Rich Authorization Requests leveraging the OpenID AuthZEN authorization request/response formats within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to request and receive relevant authorization decisions from an AuthZEN-compatible PDP in an interoperable manner. | |||||||||||||
| draft-brotman-dkim-aggregate-reporting-01.txt | ||||||||||||||
| Aggregate Reports for DKIM Signers | ||||||||||||||
|
This document introduces a mechanism enabling DKIM-signing domain owners to solicit aggregate reports from email receivers. Presented in an XML format, these reports possess adaptable elements conducive for integration with current and future drafts and standards like DMARCbis. They capture the evaluation outcomes of DKIM signatures, such as 'pass' or 'fail', alongside other potential data attributes. Receivers can relay these aggregate reports to destinations designated by the DKIM-signing domain holder, contingent upon their support capabilities. | |||||||||||||
| draft-brotman-dkim-fbl-03.txt | ||||||||||||||
| Email Feedback Reports for DKIM Signers | ||||||||||||||
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. | |||||||||||||
| draft-brotman-ietf-bimi-guidance-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brown-rdap-referrals-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brown-rdap-ttl-extension-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brw-scone-analysis-00.txt | ||||||||||||||
| SCONE Solution Analysis | ||||||||||||||
|
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. | |||||||||||||
| draft-brw-scone-rate-policy-discovery-02.txt | ||||||||||||||
| Discovery of Network Rate-Limit Policies (NRLPs) | ||||||||||||||
|
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. | |||||||||||||
| draft-brw-scone-throughput-advice-blob-02.txt | ||||||||||||||
| 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.). | |||||||||||||
| draft-bryce-cose-merkle-mountain-range-proofs-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-bucksch-mauth-00.txt | ||||||||||||||
| mAuth - OAuth2 profile for mail apps and other public clients | ||||||||||||||
|
This document creates a specific OAuth2 profile that is suitable for mail, chat, calendar and similar clients. It defines specific parameters of OAuth2, to allow email clients to reliably authenticate using OAuth2 on any mail provider. | |||||||||||||
| draft-buraglio-deprecate7050-01.txt | ||||||||||||||
| Discouraging use of RFC7050 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis | ||||||||||||||
|
RFC7050 describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation (RFC7915). This methodology depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". Because newer methods exist that lack the requirement of a higher level protocol, instead using existing operations in the form of native router advertisements, discovery of the IPv6 prefix used for protocol translation using RFC7050 should be discouraged. RFC7050 MAY only be used if other methods (such as RFC8781]) can not be used. | |||||||||||||
| draft-burdet-bess-evpn-fast-reroute-08.txt | ||||||||||||||
| EVPN Fast Reroute | ||||||||||||||
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. | |||||||||||||
| draft-burleigh-deepspace-ip-assessment-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-burleigh-regions-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bwbh-digital-emblem-model-01.txt | ||||||||||||||
| Conceptual Model for Digitized Emblems | ||||||||||||||
|
This document describes the conceptual models of use for digital emblems. | |||||||||||||
| draft-campling-ech-deployment-considerations-09.txt | ||||||||||||||
| Encrypted Client Hello Deployment Considerations | ||||||||||||||
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. | |||||||||||||
| draft-canel-robots-ai-control-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-cao-v6ops-ipv6-monitoring-deployment-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-carpenter-gendispatch-org-proc-docs-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-carter-high-assurance-dids-with-dns-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-case-ppm-binomial-dp-01.txt | ||||||||||||||
| Simple and Efficient Binomial Protocols for Differential Privacy in MPC | ||||||||||||||
|
A method for computing a binomial noise in Multiparty Computation (MPC) is described. The binomial mechanism for differential privacy (DP) is a simple mechanism that is well suited to MPC, where computation of more complex algorithms can be expensive. This document describes how to select the correct parameters and apply binomial noise in MPC. | |||||||||||||
| draft-cbs-teas-5qi-to-dscp-mapping-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cc-v6ops-wlcg-flow-label-marking-03.txt | ||||||||||||||
| Use of the IPv6 Flow Label for WLCG Packet Marking | ||||||||||||||
|
This document describes an experimentally deployed approach currently used within the Worldwide Large Hadron Collider Computing Grid (WLCG) to mark packets with their project (experiment) and application. The marking uses the 20-bit IPv6 Flow Label in each packet, with 15 bits used for semantics (community and activity) and 5 bits for entropy. Alternatives, in particular use of IPv6 Extension Headers (EH), were considered but found to not be practical. The WLCG is one of the largest worldwide research communities and has adopted IPv6 heavily for movement of many hundreds of PB of data annually, with the ultimate goal of running IPv6 only. | |||||||||||||
| draft-ccc-v6ops-address-accountability-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cds-rats-intel-corim-profile-02.txt | ||||||||||||||
| Intel Profile for CoRIM | ||||||||||||||
|
This document describes extensions to CoRIM that support Intel- specific Attester implementations and corresponding Endorsements and Reference Values. Multiple Evidence formats are anticipated, but all anticipated Evidence can be mapped to Reference Values expressions based on CoRIM and the CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers may use this profile to author mainifests containing Reference Values and Endorsements. Verifiers will recognize this profile by it's profile identifier and implement support for the extentions defined or may identify a suitable Verifier, or will refuse to process inputs. | |||||||||||||
| draft-celi-wiggers-tls-authkem-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cenzano-moq-media-interop-00.txt | ||||||||||||||
| MoQ Media Interop | ||||||||||||||
|
This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT]. | |||||||||||||
| draft-chaudhari-source-access-control-metadata-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-ati-adaptive-ipv4-address-space-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-bier-anycast-label-02.txt | ||||||||||||||
| BIER Anycast MPLS Label | ||||||||||||||
|
This document provides a method to reduce packet loss when failures occur at BIER transit or egress nodes or link. | |||||||||||||
| draft-chen-bier-idr-bier-te-bgp-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-bmwg-savnet-sav-benchmarking-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-cfrg-vdaf-pine-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-idr-bgp-ls-algo-related-adjacency-sid-04.txt | ||||||||||||||
| Algorithm Related Adjacency SID Advertisement | ||||||||||||||
|
This draft describes a mechanism to distribute SR-MPLS algorithm Related Adjacency SID from controllers to the headend routers using BGP-LS. | |||||||||||||
| draft-chen-idr-bgp-ls-security-capability-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-idr-bgp-ls-sr-policy-cp-validity-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-idr-bgp-sr-policy-cp-validity-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-lsr-adv-lkno-05.txt | ||||||||||||||
| IGP Extensions for Advertising Link Numbers | ||||||||||||||
|
This document describes OSPF and IS-IS extensions for distributing the link numbers assigned to the links originating at a node. | |||||||||||||
| draft-chen-lsr-adv-ni-05.txt | ||||||||||||||
| IGP Extensions for Advertising Node Index | ||||||||||||||
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. | |||||||||||||
| draft-chen-lsr-mpls-mna-capability-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-chen-netconf-yang-push-notif-filter-00.txt | ||||||||||||||
| Filter of Configuration Change Notifications | ||||||||||||||
|
This document extends the YANG-Push notification subscription mechanism for on-change to reduce unnecessary reporting after an on- change YANG-Push notification is generated. | |||||||||||||
| draft-chen-pce-controller-bier-te-06.txt | ||||||||||||||
| PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE | ||||||||||||||
|
This draft specify extensions to PCEP protocol when a PCE-based controller is responsible for allocates the BIER-TE information(BIER subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc), then PCC generate a "Bit Index Forwarding Table"(BIFT). | |||||||||||||
| draft-chen-pce-pcep-extension-pce-controller-bier-06.txt | ||||||||||||||
| PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER | ||||||||||||||
|
This draft specify a new mechanism where PCE allocates the BIER information centrally and uses PCEP to distribute them to all nodes, then PCC generate a "Bit Index Forwarding Table"(BIFT). | |||||||||||||
| draft-chen-pce-sr-mpls-sid-verification-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-pce-sr-policy-cp-validity-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-pim-be-mrh-05.txt | ||||||||||||||
| Stateless Best Effort Multicast Using MRH | ||||||||||||||
|
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. | |||||||||||||
| draft-chen-pim-be-mrh-simu-04.txt | ||||||||||||||
| Stateless Best Effort Multicast Simulations | ||||||||||||||
|
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. | |||||||||||||
| draft-chen-rtgwg-cco-framework-and-definition-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-sidrops-sispi-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-spring-sr-policy-cp-validity-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-spring-srv6-compressed-bsid-insertion-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-tsvwg-high-speed-data-express-00.txt | ||||||||||||||
| High speed data express in IP: Concept,Reference Architecture and Technologies | ||||||||||||||
|
With the rapid development of AI technology, intelligent computing and super-computing services, the demand for wide-area transmission of massive data is increasing. This paper makes full use of the advantages of IP network, such as statistical reuse and elastic supply, and proposes a reference architecture of high elasticity and high throughput data express based on IP network. In order to support differentiated data express services and create task-type data express services, the "one low and three high" technical system is proposed. | |||||||||||||
| draft-chen-tsvwg-updated-ack-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-x509-anonymous-voting-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-6man-source-address-programmability-03.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-cheng-idr-conformance-forwarding-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-adv-savnet-capbility-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-advertise-nrp-group-extensions-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-extension-opt-srv6-sid-adv-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-igp-shortcut-enhancement-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-ospf-adjacency-suppress-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-rift-srv6-extensions-03.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-cheng-rtgwg-adaptive-routing-framework-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-rtgwg-ai-network-reliability-problem-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-rtgwg-srv6-multihome-egress-protection-07.txt | ||||||||||||||
| SRv6 Egress Protection in Multi-homed scenario | ||||||||||||||
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. | |||||||||||||
| draft-cheng-savnet-inter-domain-oam-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-savnet-intra-domain-oam-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-savnet-intra-domain-sav-bgp-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-savnet-intra-domain-sav-igp-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-savnet-proactive-defense-network-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-sidrops-consistency-forwarding-00.txt | ||||||||||||||
| Definition and Problem Statement of consistency inter-domain routing and forwarding | ||||||||||||||
|
This document introduces what the consistency forwarding is and why inconsistency forwarding is prevalent in the Internet, describes the risks of inconsistency forwarding and defines the requiremenets for consistency forwarding. | |||||||||||||
| draft-cheng-spring-service-interworking-srv6-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-spring-sr-policy-group-06.txt | ||||||||||||||
| SR Policy Group | ||||||||||||||
|
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 | |||||||||||||
| draft-cheng-spring-srv6-encoding-network-sliceid-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-spring-srv6-policy-resource-gurantee-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-spring-stateless-nd-srv6-locator-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chenruihao-globalaccelerator-00.txt | ||||||||||||||
| An method of evaluating global accelerator based on cloud networking. | ||||||||||||||
|
This document intends to serve as a standard for a global accelerator. | |||||||||||||
| draft-cheshire-sbm-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chins-dnsop-web3-wallet-mapping-01.txt | ||||||||||||||
| DNS to Web3 Wallet Mapping | ||||||||||||||
|
This document proposes a implementation standard for mapping wallets to domain names using the new WALLET RRType, while allowing for TXT record fallback. The goal is to provide a secure and scalable 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. We also will propose a mechanism for mapping a wallet back to a domain name. | |||||||||||||
| draft-choi-6lo-owc-security-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chroboczek-intarea-v4-via-v6-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chung-ccwg-search-02.txt | ||||||||||||||
| SEARCH -- a New Slow Start Algorithm for TCP and QUIC | ||||||||||||||
|
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 -- 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 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. | |||||||||||||
| draft-cisco-skip-00.txt | ||||||||||||||
| Secure Key Integration Protocol (SKIP) | ||||||||||||||
|
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. | |||||||||||||
| draft-clw-6man-rfc8504-bis-01.txt | ||||||||||||||
| IPv6 Node Requirements | ||||||||||||||
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. | |||||||||||||
| draft-colitti-ipsecme-esp-ping-03.txt | ||||||||||||||
| ESP Echo Protocol | ||||||||||||||
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. | |||||||||||||
| draft-colwell-privacy-txt-01.txt | ||||||||||||||
| A File Format to Aid in Consumer Privacy Enforcement,Research,and Tools | ||||||||||||||
|
This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txt [RFC9309], security.txt [RFC9116], or ads.txt [ADS-TXT], in the / directory or /.well-known directory. The file format adds structured data for three areas: 1. A machine parsable and complete privacy policy 2. Consumer actions under their privacy rights 3. Cookie disclosures | |||||||||||||
| draft-connolly-cfrg-hpke-mlkem-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-connolly-cfrg-hybrid-sig-considerations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-connolly-cfrg-xwing-kem-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-connolly-tls-mlkem-key-agreement-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-contario-totp-secure-enrollment-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-contreras-bmwg-calibration-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-contreras-coinrg-clas-evolution-03.txt | ||||||||||||||
| An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness | ||||||||||||||
|
This document proposes an extension to the Cooperating Layered Architecture for Software-Defined Networking (SDN) by including compute resources and data analysis processing capabilities. | |||||||||||||
| draft-contreras-nmrg-green-intent-00.txt | ||||||||||||||
| Intent for Green Services | ||||||||||||||
|
There is an increasing interest on incorporating sustainable dimension to the provision of commnunication services. This document describes an intent for allowing customers to express their desired intents in terms of the green service objectives they expect from the network provider. | |||||||||||||
| draft-contreras-nmrg-interconnection-intents-05.txt | ||||||||||||||
| Interconnection Intents | ||||||||||||||
|
This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. | |||||||||||||
| draft-contreras-nmrg-transport-slice-intent-07.txt | ||||||||||||||
| IETF Network Slice Intent | ||||||||||||||
|
Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introduction of new services such as 5G. This document explores the usage of intent technologies for requesting IETF network slices. | |||||||||||||
| draft-contreras-opsawg-scheduling-oam-tests-04.txt | ||||||||||||||
| A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests | ||||||||||||||
|
This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures. | |||||||||||||
| draft-contreras-pce-pam-03.txt | ||||||||||||||
| Path Computation Based on Precision Availability Metrics | ||||||||||||||
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. | |||||||||||||
| draft-contreras-pim-multiif-config-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-contreras-tvr-alto-exposure-05.txt | ||||||||||||||
| Using ALTO for exposing Time-Variant Routing information | ||||||||||||||
|
Network operations can require time-based, scheduled changes in nodes, links, adjacencies, etc. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can assist, as an off-path mechanism, on the exposure of such predicted changes to both internal and external applications then anticipating the occurrence of routing changes. This document describes how ALTO helps in that purpose. | |||||||||||||
| draft-coretta-ldap-subnf-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-coretta-oiddir-radit-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-coretta-oiddir-radsa-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-coretta-oiddir-radua-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-coretta-oiddir-roadmap-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-coretta-oiddir-schema-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-correia-scim-use-cases-03.txt | ||||||||||||||
| System for Cross-domain Identity Management: Definitions,Overview,Concepts,and Requirements | ||||||||||||||
|
This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. | |||||||||||||
| draft-cprjgf-bmwg-powerbench-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-crocker-dnsop-dnssec-algorithm-lifecycle-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cui-dots-extended-yang-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cui-idr-content-filter-flowspec-03.txt | ||||||||||||||
| Packet Content Filter for BGP FlowSpec | ||||||||||||||
|
The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filter in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address volumetric DDoS attack traffic characterized by fixed patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes ptype, otype, offset, content-length, content, and mask encoded in the Flowspec NLRI. This new filter aims to leverage network devices such as routers and switches to defend against simple volumetric DDoS attacks, reducing the overall defence cost of carrier network. | |||||||||||||
| draft-cui-savnet-anti-ddos-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cwbgp-green-energy-saving-management-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cx-green-green-metrics-00.txt | ||||||||||||||
| Green Networking Metrics for Environmentally Sustainable Networking | ||||||||||||||
|
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. | |||||||||||||
| draft-cx-mpls-mna-inband-pm-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cxx-ippm-ioamaggr-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cz-bier-bgp-ls-bier-te-ext-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dai-sfc-fused-architecture-and-scenario-06.txt | ||||||||||||||
| Architecture and application scenario for fused service function chain | ||||||||||||||
|
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. | |||||||||||||
| draft-dai-sfc-fused-protocol-and-procedure-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-daley-gendispatch-venue-requirements-03.txt | ||||||||||||||
| IETF Meeting Venue Requirements Review | ||||||||||||||
|
Following a review of the IETF meeting venue requirements, this document proposes updates to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and proposes a replacement exploratory meeting process, thereby updating RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF". | |||||||||||||
| draft-danet-qkdn-considerations-00.txt | ||||||||||||||
| Initial Considerations about QDKN Protocols | ||||||||||||||
|
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. | |||||||||||||
| draft-davidben-tls-merkle-tree-certs-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-davidben-tls-trust-expr-04.txt | ||||||||||||||
| TLS Trust Expressions | ||||||||||||||
|
This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. | |||||||||||||
| draft-davidben-x509-alg-none-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-davies-internal-tld-01.txt | ||||||||||||||
| A Top-level Domain for Private Use | ||||||||||||||
|
This document describes the "internal" top-level domain for use in private applications. | |||||||||||||
| draft-davis-nmop-some-refinements-to-rfc8345-00.txt | ||||||||||||||
| Some Refinements to Network Topologies (RFC8345) | ||||||||||||||
|
This draft provides a brief analysis of the current unidirectional point-to-point approach to modeling of the link in RFC8345, highlights why this is not sufficient and makes a proposal to enhance RFC8345 YANG to support multipoint uni/bi links. The two alternative enhancement approaches proposed are backward compatible. The enhancement is such that it provides a uniform solution to modeling all links that could, over time, replace the current unidirectional point-to-point approach. The rationale for the change is based on many years of practical experience, including challenges using RFC8345 in actual solution development, and insight gained through other standardisation efforts and deployments. | |||||||||||||
| draft-dcn-dmm-cats-mup-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dearlove-manet-olsrv2-responsive-01.txt | ||||||||||||||
| 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)". | |||||||||||||
| draft-deeglaze-amd-sev-snp-corim-profile-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-deen-mops-network-overlay-impacts-02.txt | ||||||||||||||
| Network Overlay Impacts to Streaming Video | ||||||||||||||
|
This document examines the operational impacts to streaming video applications caused by changes to network policies by network overlays. The network policy changes include IP address assignment, transport protocols, routing, DNS resolver which in turn affect a variety of important content delivery aspects such as latency, CDN cache selection, delivery path choices, traffic classification and content access controls. | |||||||||||||
| draft-defoy-moq-relay-network-handling-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dejong-decentralized-cycle-detection-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dejong-remotestorage-24.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dekater-scion-controlplane-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dekater-scion-dataplane-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dekater-scion-pki-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-demarco-oauth-status-assertions-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-deng-rtgwg-sr-loop-free-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-denis-dprive-dnscrypt-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-denis-tls-aegis-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-deshpande-secevent-http-multi-push-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dhody-pce-pcep-extension-pce-controller-p2mp-13.txt | ||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs | ||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path, while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. | |||||||||||||
| draft-dhody-pce-pcep-object-order-06.txt | ||||||||||||||
| 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 message are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. | |||||||||||||
| draft-dhody-teas-ietf-network-slice-mapping-05.txt | ||||||||||||||
| 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 resource and TE/VPN models. | |||||||||||||
| draft-dhody-teas-te-traffic-yang-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-diaz-lzip-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dijkhuis-cfrg-hdkeys-01.txt | ||||||||||||||
| 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. 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-dijkhuis-cfrg-hdkeys/. Source for this draft and an issue tracker can be found at https://github.com/sander/hierarchical-deterministic-keys. | |||||||||||||
| draft-dkg-openpgp-1pa3pc-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dkg-openpgp-external-secrets-01.txt | ||||||||||||||
| OpenPGP External Secret Keys | ||||||||||||||
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem. | |||||||||||||
| draft-dkg-openpgp-prompting-caching-00.txt | ||||||||||||||
| OpenPGP Prompting and Caching | ||||||||||||||
|
Some OpenPGP secret keys and messages are locked with a passphrase. An OpenPGP-using application might want to prompt the user for the passphrase, or might want to permit the user to only enter the passphrase once while keeping the material unlocked for future use. This document describes a simple interface that can be used for prompting the user and for caching the results of such a prompt. It is designed to interoperate well with the Stateless OpenPGP Interface, and to facilitate its use both in test suite operations and in common patterns of interactive operation. | |||||||||||||
| draft-dkg-openpgp-stateless-cli-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dmc-idr-flowspec-tn-aware-mobility-05.txt | ||||||||||||||
| BGP Dissemination of FlowSpec for Transport Aware Mobility | ||||||||||||||
|
This document defines a BGP Flow Specification (FlowSpec) extension to disseminate the policies from 5G mobile networks. This allows the 5G mobile systems slices and Service Types (SSTs) can be mapped to optimal underlying network paths in the data network outside the 5G UPFs, specifically at the N6 interface in 3GPP 5G Architecture [3GPP TR 23.501]. | |||||||||||||
| draft-dnoveck-nfsv4-acls-05.txt | ||||||||||||||
| ACLs within the NFSv4 Protocols | ||||||||||||||
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis respecification effort for NFv4.1. It describes the structure and function of Access Control Lists within all existing minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. [Consensus Needed (Item #117a)]: Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was originally intended, this document clarifies the status of draft POSIX ACLs, with the expectation that support for these might be provided via a later extension. In addition, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. [Consensus Needed (Item #117a)]: In this document, the relationship among the multiple ACL models supported has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now-withdrawn draft POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft POSIX ACL model are considered as OPTIONAL extensions to that core, with the latter not yet present in NFsv4.1. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. | |||||||||||||
| draft-dnoveck-nfsv4-rfc5662bis-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dnoveck-nfsv4-security-11.txt | ||||||||||||||
| 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, | |||||||||||||
| draft-dong-idr-bgp-ls-scalable-nrp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dong-idr-bgp-nrp-policy-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dong-lsr-l2bundle-srv6-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dong-lsvr-bgp-spf-selection-01.txt | ||||||||||||||
| Proposed Update to BGP Link-State SPF NLRI Selection Rules | ||||||||||||||
|
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, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. | |||||||||||||
| draft-dong-pce-pcep-nrp-02.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) | ||||||||||||||
|
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. | |||||||||||||
| draft-dong-spring-sr-4map6-segments-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dong-spring-sr-policy-with-nrp-00.txt | ||||||||||||||
| Associating Segment Routing (SR) Policy with Network Resource Partition (NRP) | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP) is a subset of the network resources and associated policies in the underlay network, which can be used to support one or a group of Enhanced VPN or RFC 9543 network slice services. In SR networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. Within an NRP, SR Policy can be used for forwarding traffic which is mapped to the NRP, so that the traffic can be provided with the subset of network resources and policy of the NRP for guaranteed performance. The association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. | |||||||||||||
| draft-dong-spring-srv6-inter-layer-programming-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-doujiali-cloudnetwork-intelligentoperation-00.txt | ||||||||||||||
| An requirement of Cloud Network Intelligent Operation and Maintenance. | ||||||||||||||
|
This document intends to serve as a standard for Cloud Network Intelligent Operation and Maintenance. | |||||||||||||
| draft-dreibholz-ipv4-flowlabel-40.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-rserpool-applic-distcomp-37.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-rserpool-applic-mobility-36.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-dreibholz-rserpool-asap-hropt-35.txt | ||||||||||||||
| Handle Resolution Option for ASAP | ||||||||||||||
|
This document describes the Handle Resolution option for the ASAP protocol. | |||||||||||||
| draft-dreibholz-rserpool-delay-34.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-rserpool-enrp-takeover-32.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-rserpool-nextgen-ideas-22.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-rserpool-score-35.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-taps-neat-socketapi-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-tsvwg-sctp-nextgen-ideas-20.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-multipath-29.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-sqinfo-29.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-du-cats-aggregated-metrics-on-egress-00.txt | ||||||||||||||
| Aggregated Metrics on Egress Node and Corresponding Routing Mechanism | ||||||||||||||
|
This document describes aggregated metrics on the Egress node and the corresponding routing mechanism for Computing-Aware Traffic Steering (CATS). | |||||||||||||
| draft-du-cats-computing-modeling-description-03.txt | ||||||||||||||
| Computing Information Description in Computing-Aware Traffic Steering | ||||||||||||||
|
This document describes the considerations and requirements of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). | |||||||||||||
| draft-du-rtgwg-in-network-congestion-notification-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-du-tsvwg-odes-problem-statement-01.txt | ||||||||||||||
| Use Cases and Problem Statements of Online Data Express Service | ||||||||||||||
|
This document describes use cases and problem statements of Online Data Express Service. | |||||||||||||
| draft-duan-bess-mvpn-ipv6-infras-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-duan-bess-simplified-mvpn-for-bier-and-ir-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-duffy-csmp-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dulaunoy-dnsop-passive-dns-cof-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dulaunoy-misp-core-format-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dunbar-neotec-net-adjust-cloud-scaling-01.txt | ||||||||||||||
| Dynamic Network Adjustments for Cloud Service Scaling | ||||||||||||||
|
This document specifies a framework for dynamically adjusting network configurations in response to cloud service scaling events. As cloud services grow, increase traffic, or add resources, automatically adapting network configurations can improve performance and enable greater interoperability. Manual network adjustments are often slow, error-prone, and inadequate for the rapid changes of cloud services. The proposed framework, along with the associated YANG models, facilitates seamless interoperability among network controllers and equipment from various vendors, which is an essential requirement for Telecom Cloud providers operating in multi-vendor environments. | |||||||||||||
| draft-dunbar-secdispatch-ligthtweight-authenticate-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dutt-nvo3-rfc7348bis-00.txt | ||||||||||||||
| Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks | ||||||||||||||
|
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. | |||||||||||||
| draft-dxs-neotec-crossdomain-net-mgnt-dm-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-6man-hide-options-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-dnsop-expressing-qos-requirements-05.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-eastlake-dnsop-rfc2930bis-tkey-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-dnsop-rfc2931bis-sigzero-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-dnsop-rrtype-srv6-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-dnsop-svcb-rr-tunnel-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-fnv-29.txt | ||||||||||||||
| The FNV Non-Cryptographic Hash Algorithm | ||||||||||||||
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that is referenced in a number of standards documents and widely used. 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. | |||||||||||||
| draft-eastlake-lldp-mac-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-rfc3797bis-06.txt | ||||||||||||||
| Publicly Verifiable Nominations Committee (NomCom) Random Selection | ||||||||||||||
|
This document describes a method for making random selections in such a way as to promote public confidence in the unbiased nature of the choice. This method is referred to in this document as "verifiable selection". It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar techniques could be and have been applied to other selections. It provdes an optional extension for multiple rounds of such selection that can be induced by earlier selectees without compromising the unpredictable nature of the selections. This document obsoletes RFC 3797. | |||||||||||||
| draft-eastlake-rfc9231bis-xmlsec-uris-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-secdispatch-tenantid-consid-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eastlake-sfc-parallel-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ecahc-moderation-01.txt | ||||||||||||||
| IETF Community Moderation | ||||||||||||||
|
This document describes the creation of a moderator team for all of the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration. | |||||||||||||
| draft-eckel-edm-find-code-05.txt | ||||||||||||||
| Find Code Related to an Internet-Draft or RFC | ||||||||||||||
|
Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and find such code. | |||||||||||||
| draft-eckert-anima-grasp-dnssd-07.txt | ||||||||||||||
| DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) | ||||||||||||||
|
DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. | |||||||||||||
| draft-eckert-anima-services-dns-autoconfig-05.txt | ||||||||||||||
| Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP | ||||||||||||||
|
This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. | |||||||||||||
| draft-eckert-detnet-flow-interleaving-02.txt | ||||||||||||||
| Deterministic Networking (DetNet) Data Plane - Flow interleaving for scaling detnet data planes with minimal end-to-end latency and large number of flows. | ||||||||||||||
|
This memo explain requirements, benefits and feasibility of a new DetNet service function tentatively called "flow interleaving". It proposes to introduce this service function into the DetNet architecture. Flow interleaving can be understood as a DetNet equivalent of the IEEE TSN timed gates. Its primary role is intended to be at the ingress edge of DetNet domains supporting higher utilization and lower bounded latency for flow aggregation (interleaving of flows into a single flow), as well as higher utilization and lower bounded latency for interleaving occurring in transit hops of the DetNet domain in conjunction with in-time per-hop bounded latency forwarding mechanisms. | |||||||||||||
| draft-eckert-detnet-glbf-03.txt | ||||||||||||||
| Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks | ||||||||||||||
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. | |||||||||||||
| draft-eckert-detnet-tcqf-06.txt | ||||||||||||||
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets | ||||||||||||||
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. | |||||||||||||
| draft-eckert-ietf-and-energy-overview-07.txt | ||||||||||||||
| An Overview of Energy-related Effort within the IETF | ||||||||||||||
|
This memo provides an overview of work performed by or proposed within the IETF related to energy and/or green: awareness, management, control or reduction of consumption of energy, and sustainability as it related to the IETF. This document is written to help those unfamiliar with that work, but interested in it, in the hope to raise more interest in energy- related activities within the IETF, such as identifying gaps and investigating solutions as appropriate. This document captures work until 12/2022, at which time the "IAB workshop on Environmental Impact of Internet Applications and Systems" revived interest and triggered new work in the topic within the IETF/IRTF. | |||||||||||||
| draft-eckert-pim-rts-forwarding-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eddy-scone-api-00.txt | ||||||||||||||
| APIs To Expose SCONE Metadata to Applications | ||||||||||||||
|
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. | |||||||||||||
| draft-edm-protocol-greasing-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-edwards-telnet-xon-xoff-state-control-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eggert-ietf-chair-may-delegate-02.txt | ||||||||||||||
| The IETF Chair May Delegate | ||||||||||||||
|
This document proposes that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates several existing RFCs to enable that. It also proposes a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. | |||||||||||||
| draft-ehlen-openpgp-nist-bp-comp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-eip-arch-04.txt | ||||||||||||||
| Extensible In-band Processing (EIP) Architecture and Framework | ||||||||||||||
|
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. | |||||||||||||
| draft-eknb-srv6ops-interdomain-sidspace-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-engelbart-avtcore-rtcp-point-cloud-roi-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-engelbart-qlog-roq-events-00.txt | ||||||||||||||
| RoQ qlog event definitions | ||||||||||||||
|
This document describes concrete qlog event definitions and their metadata for RTP over QUIC [I-D.draft-ietf-avtcore-rtp-over-quic] related events. These events can then be embedded in the higher level schema defined in [I-D.draft-ietf-quic-qlog-main-schema]. | |||||||||||||
| draft-equinox-intarea-dhcpv4-route4via6-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-equinox-v6ops-icmpext-xlat-v6only-source-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farinacci-lisp-decent-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farinacci-lisp-lispers-net-nat-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farinacci-lisp-satellite-network-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farrell-errata-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farrell-tls-pemesni-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-farrell-tls-pqg-00.txt | ||||||||||||||
| Post-Quantum Guidance for TLS. | ||||||||||||||
|
We provide guidance on the use of post-quantum algorithms for those deploying applications using TLS. | |||||||||||||
| draft-fbw-dnsop-dnszonehop-00.txt | ||||||||||||||
| Zone Hopping: A method to prevent zone-walking in DNSSEC | ||||||||||||||
|
DNS Security Extension (DNSSEC) as defined by [RFC9364] was developed to address significant security integrity flaws in DNS. Within certain circumstances, information leakage may be possible stemming from a known DNSSEC vulnerability that facilitates a process known as zone walking, which enables the efficient collection of all FQDNs from a given environment. This document describes the problem space as outlined in [IEEE-ZoneHopping] and offers a potential solution, called Zone-Hopping, to aid in addressing the domain information leakage capable via Zone-walking while preserving the integrity of the records for which DNSSEC was originally introduced. | |||||||||||||
| draft-fdb-rats-psa-endorsements-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fenner-intarea-probe-clarification-02.txt | ||||||||||||||
| PROBE: A Utility for Probing Interfaces | ||||||||||||||
|
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. | |||||||||||||
| draft-fetch-validation-vmc-wchuang-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ffm-rats-cca-token-00.txt | ||||||||||||||
| Arm's Confidential Compute Architecture Reference Attestation Token | ||||||||||||||
|
The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA 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. | |||||||||||||
| draft-fft-architecture-00.txt | ||||||||||||||
| Fast Fault Tolerance Architecture for Programmable Datacenter Networks | ||||||||||||||
|
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. | |||||||||||||
| draft-fiebig-grow-routing-ops-sec-inform-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fiebig-grow-routing-ops-terms-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-filsfils-ippm-path-tracing-02.txt | ||||||||||||||
| Path Tracing in SRv6 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 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. | |||||||||||||
| draft-filsfils-spring-path-tracing-srmpls-05.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-filsfils-spring-srv6-stateless-slice-id-10.txt | ||||||||||||||
| Stateless and Scalable Network Slice Identification for SRv6 | ||||||||||||||
|
This document defines a stateless and scalable solution to achieve network slicing with SRv6. | |||||||||||||
| draft-fioccola-ippm-on-path-active-measurements-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fizgeer-pce-pcep-bfd-parameters-03.txt | ||||||||||||||
| PCEP Extensions to support BFD parameters | ||||||||||||||
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. | |||||||||||||
| draft-fluechter-bier-bierte-subset-tunneling-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fluhrer-lms-more-parm-sets-17.txt | ||||||||||||||
| Additional Parameter sets for HSS/LMS Hash-Based Signatures | ||||||||||||||
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | |||||||||||||
| draft-fondevik-mls-pairedmls-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fossati-rats-message-types-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fossati-tls-attestation-08.txt | ||||||||||||||
| Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
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. | |||||||||||||
| draft-francois-grow-bmp-loc-peer-04.txt | ||||||||||||||
| BMP Loc-RIB: Peer address | ||||||||||||||
|
BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. | |||||||||||||
| draft-fregly-dnsop-slh-dsa-mtl-dnssec-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fregly-research-agenda-for-pqc-dnssec-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-frindell-moq-chat-00.txt | ||||||||||||||
| MoQ Chat | ||||||||||||||
|
MoQ Chat (moq-chat) is a simple text based protocol for exercising MoQ Transport. | |||||||||||||
| draft-frochet-quicwg-reverso-for-quic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fu-cats-flow-lb-00.txt | ||||||||||||||
| Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document proposes a flow-level load balancing solution for CATS, and is designed to effectively manage CS-ID traffic by addressing issues like frequent control plane operations and uneven use of computing resources. The approach entails concurrently identifying multiple next-hop choices, factoring in both network pathways and service instances. Traffic is then distributed among these service instances using flow-based load balancing, which relies on the five- tuple characteristics of packets. | |||||||||||||
| draft-fu-cats-muti-dp-solution-01.txt | ||||||||||||||
| Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering | ||||||||||||||
|
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. | |||||||||||||
| draft-fu-cats-oam-fw-01.txt | ||||||||||||||
| Operations,Administration and Maintenance (OAM) for Computing-Aware Traffic Steering | ||||||||||||||
|
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. | |||||||||||||
| draft-fu-cats-sr-te-based-solution-02.txt | ||||||||||||||
| An SR-TE based Solution For Computing-Aware Traffic Steering | ||||||||||||||
|
Computing-aware traffic steering (CATS) is a traffic engineering approach [I-D.ietf-teas-rfc3272bis] that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. Various relevant metrics may be used to enforce such computing-aware traffic steering policies.It is critical to meet different types of computing-aware traffic steering requirements without disrupting the existing network architecture. In this context, this document proposes a computing-aware traffic steering solution based on the SR- TE infrastructure of the current traffic engineering technology to reduce device resource consumption and investment and meet the requirements for computing-aware traffic steering of network devices. | |||||||||||||
| draft-fu-sidrops-enhanced-slurm-filter-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fujiwara-dnsop-dns-upper-limit-values-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fv-rats-ear-04.txt | ||||||||||||||
| EAT Attestation Results | ||||||||||||||
|
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. | |||||||||||||
| draft-fz-ippm-on-path-telemetry-yang-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fz-spring-srv6-alt-mark-09.txt | ||||||||||||||
| Application of the Alternate Marking Method to the Segment Routing Header | ||||||||||||||
|
The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. This protocol extension has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale deployment to determine the potential benefits of this approach. | |||||||||||||
| draft-gage-quic-pathmgmt-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gallagher-openpgp-hkp-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gallagher-openpgp-signatures-00.txt | ||||||||||||||
| OpenPGP Signatures and Signed Messages | ||||||||||||||
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. | |||||||||||||
| draft-galvin-regext-epp-variants-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gandhi-ippm-simple-direct-loss-08.txt | ||||||||||||||
| Simple Two-Way Direct Loss Measurement Procedure | ||||||||||||||
|
This document defines Simple Two-Way Direct Loss Measurement (DLM) procedure that can be used for Alternate-Marking Method for detecting accurate data packet loss in a network. Specifically, DLM probe packets are defined for both unauthenticated and authenticated modes and they are efficient for hardware-based implementation. | |||||||||||||
| draft-gandhi-mpls-mna-ioam-dex-01.txt | ||||||||||||||
| MPLS Network Actions for Transporting In Situ Operations,Administration,and Maintenance (IOAM) Data Fields and Direct Exporting | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document defines MPLS Network Actions for transporting IOAM data fields as well as direct exporting them. | |||||||||||||
| draft-gao-cats-service-announcement-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gao-flexible-session-protocol-13.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-gao-neotec-interface-cnc-00.txt | ||||||||||||||
| Analysis of Service Management Interface for Cloud-network Convergence | ||||||||||||||
|
This document analyzes the cloud-network convergence service management interface. | |||||||||||||
| draft-gao-quic-network-awareness-ack-00.txt | ||||||||||||||
| QUIC network awareness Acknowledgements | ||||||||||||||
|
This document defines a quic ACK frame format for notifying network status information. | |||||||||||||
| draft-gasser-opsawg-prefix-lengths-02.txt | ||||||||||||||
| Publishing End-Site Prefix Lengths | ||||||||||||||
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. | |||||||||||||
| draft-geng-acme-public-key-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-geng-bmwg-srv6-service-guideline-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-geng-idr-bgp-savnet-04.txt | ||||||||||||||
| BGP Extensions for Source Address Validation Networks (BGP SAVNET) | ||||||||||||||
|
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. | |||||||||||||
| draft-geng-idr-flowspec-sav-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-geng-sidrops-aspa-analysis-01.txt | ||||||||||||||
| An Analysis of ASPA-based AS_PATH Verification | ||||||||||||||
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies. The document can help people deploy ASPA properly and provide some potential directions of enhancing ASPA. | |||||||||||||
| draft-geng-sidrops-asra-profile-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-geng-sidrops-rtr-selective-sync-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ginsberg-lsr-flex-soft-dataplane-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-glctgp-lsr-l2-bundle-member-remote-id-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-goldstein-processing-stages-metadata-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gomez-core-coap-bp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gomez-core-coap-space-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gondwana-dkim2-modification-alegbra-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gondwana-dkim2-motivation-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-lsr-flex-algo-exclude-node-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-hierarchical-slice-solution-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-lldp-srv6-extensions-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-nd-advertise-srv6-locator-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-ping-path-consistency-over-srv6-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-sr-policy-group-yang-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gong-spring-srv6-nrp-flavor-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gont-6man-rfc8028-update-00.txt | ||||||||||||||
| Support for Multi-Router and Multi-Prefix IPv6 Networks | ||||||||||||||
|
This document specifies IPv6 host behavior to improve their support for general and common multi-router and multi-prefix scenarios. It formally updates RFC 4861, RFC 4862, and RFC 8028 such that such scenarios are properly supported. This document also formally updates RFC 8504, thus requiring support for multi-router and multi- prefix scenarios in all IPv6 nodes. | |||||||||||||
| draft-gont-v6ops-multi-ipv6-00.txt | ||||||||||||||
| Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces | ||||||||||||||
|
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. | |||||||||||||
| draft-grayson-connectinfo-00.txt | ||||||||||||||
| A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks | ||||||||||||||
|
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. | |||||||||||||
| draft-gredler-idr-bgplu-epe-16.txt | ||||||||||||||
| Egress Peer Engineering using BGP-LU | ||||||||||||||
|
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. | |||||||||||||
| draft-guan-6man-ipv6-id-authentication-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gudi-t2trg-senml-as-coreconf-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gueron-cfrg-dndkgcm-01.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-gulbrandsen-smtputf8-nice-addresses-01.txt | ||||||||||||||
| Nice Email Addresses for SMTPUTF8 | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: this contains recommendations for what addresses humans should use, such address provisioning sytems can restrain themselves to addresses that email valdidators accept. (This set can also be described in other ways, including "simple to cut-and-paste".) Its companion defines simpler rules, accepts more addresses, and is intended for software like MTAs. NOTE: The term 'nice' is not ideal here, and must be reconsidered or replaced before this is issued as an RFC. "Well-formed" is a candidate. "Nice" will do for now: better to argue about substance than wording. | |||||||||||||
| draft-gulbrandsen-smtputf8-syntax-00.txt | ||||||||||||||
| SMTPUTF8 address syntax | ||||||||||||||
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: This is simple to implement, contains only globally viable rules and is intended to be usable for software such an MTA. Its companion defines has more complex rules, takes regional usage into account and aims to allow only addresses that are readable and cut-and-pastable to some audience. | |||||||||||||
| draft-guo-detnet-jitter-reduction-mechanism-03.txt | ||||||||||||||
| Jitter Reduction Mechanism for DetNet | ||||||||||||||
|
In large-scale deterministic networks (LDN), App-flows need to span multiple deterministic network domains, and the latency in multiple domains is added together. The jitter will be increased. In order to realize the protection service function, App-flows should be transmitted on multiple paths. The delay difference in data transmission on different paths is no different from jitter in end- to-end services. Jitter generated by various factors needs to be reduced to meet business requirements. This document describes the end-to-end jitter reduction mechanism in an LDN. This mechanism can effectively control the end-to-end jitter to meet specific business needs and make the planning of multiple paths for service protection more flexible. | |||||||||||||
| draft-guo-ipsecme-ikev2-using-shangmi-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-guo-pake-in-tls-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-guo-pake-pha-tls-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gupta-httpbis-per-resource-events-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gurel-moq-track-switching-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gutmann-pkcs15-01.txt | ||||||||||||||
| PKCS #15 Updates | ||||||||||||||
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. | |||||||||||||
| draft-gutmann-ssh-preauth-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gutmann-tls-lts-14.txt | ||||||||||||||
| TLS 1.2 Update for Long-term Support | ||||||||||||||
|
This document specifies an update of TLS 1.2 for long-term support 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. | |||||||||||||
| draft-haas-idr-bgp-attribute-escape-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-haas-savnet-bgp-sav-distribution-00.txt | ||||||||||||||
| Distribution of Source Address Validation State in BGP | ||||||||||||||
|
Source Address Validation (SAV) is a technique that can be used to mitigate source address spoofing. draft-huang-savnet-sav-table codifies the concept of source address validation on a per-incoming interface basis, the validation mode, and the traffic handling policy as a "SAV Table". This document defines a mechanism for distributing logical SAV Tables in BGP. This mechanism is addresses inter-domain SAV use cases. These SAV Tables may be used to implement appropriate device-specific validation for source addresses. | |||||||||||||
| draft-haberman-digital-emblem-ps-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-habib-voxelvideo-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hale-mls-combiner-01.txt | ||||||||||||||
| Flexible Hybrid PQ MLS Combiner | ||||||||||||||
|
This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ security that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e. an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. | |||||||||||||
| draft-halen-fed-tls-auth-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-everything-02.txt | ||||||||||||||
| 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 . | |||||||||||||
| draft-hallambaker-mesh-architecture-23.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-callsign-04.txt | ||||||||||||||
| 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 . | |||||||||||||
| draft-hallambaker-mesh-cryptography-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-dare-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-developer-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-notarization-02.txt | ||||||||||||||
| 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 . | |||||||||||||
| draft-hallambaker-mesh-platform-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-presence-03.txt | ||||||||||||||
| 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 . | |||||||||||||
| draft-hallambaker-mesh-protocol-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-rud-04.txt | ||||||||||||||
| 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 . | |||||||||||||
| draft-hallambaker-mesh-schema-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-mesh-udf-19.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hallambaker-palimpsest-00.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-hallambaker-web-service-discovery-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-haluska-sipping-directory-assistance-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-han-pce-fgotn-pcep-extension-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-han-rtgwg-wan-lossless-terms-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-happel-sml-structured-vacation-notices-01.txt | ||||||||||||||
| Structured vacation notices | ||||||||||||||
|
This document describes a machine-readable format for vacation notice messages. It is supposed to be used in conjunction with conventional, human-readable vacation notices. Structured vacation notices are based on the "structured email" specifications defined in [I-D.ietf-sml-structured-email-01] and related drafts. | |||||||||||||
| draft-happel-structured-email-trust-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hares-idr-bgp-community-attribute-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hares-idr-fsv2-more-ip-actions-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hares-idr-fsv2-more-ip-filters-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-haresh-sushrut-mib-classification-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-harvey-cfrg-mtl-mode-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-harvey-cfrg-mtl-mode-considerations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-havel-nmop-digital-map-02.txt | ||||||||||||||
| Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives | ||||||||||||||
|
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. | |||||||||||||
| draft-haynes-nfsv4-erasure-encoding-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-haynes-nfsv4-flexfiles-v2-00.txt | ||||||||||||||
| Parallel NFS (pNFS) Flexible File Layout Version 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 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 protection is also added to provide integrity. Both Client-side mirroring and the Mojette algorithm are used for data protection. | |||||||||||||
| draft-haynes-nfsv4-mojette-encoding-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-haynes-nfsv4-uncacheable-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-hcl-idr-extend-tunnel-egress-point-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hcl-rtgwg-ai-network-problem-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hcl-rtgwg-osf-framework-01.txt | ||||||||||||||
| A OSF Framework for Artificial Intelligence (AI) Network | ||||||||||||||
|
This document describes a framework for Artificial Intelligence (AI) network, Particularly, the document identifies a set of AI network components, describes their interactions, and exemplifies the workflow of the control and data planes. | |||||||||||||
| draft-he-6man-icmpv6-extensions-ipv6-ext-header-03.txt | ||||||||||||||
| LOOPBACK6: A Utility For Detecting IPv6 Extension Header Changes | ||||||||||||||
|
This document describes LOOPBACK6. LOOPBACK6 is a utility that network operators can use to determine how IPv6 extension headers have been altered by transit nodes. Its operation is similar to that of PING and PROBE. | |||||||||||||
| draft-he-ippm-ioam-dex-extensions-incorporating-am-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-he-ippm-ioam-extensions-incorporating-am-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-he-ipsecme-vpn-shared-ipsecsa-01.txt | ||||||||||||||
| Shared Use of IPsec Tunnel in a Multi-VPN Environment | ||||||||||||||
|
In a multi-VPN environment, currently, different IPsec tunnels (i.e., different IKE SAs and Child SAs) have to be created to differentiate and protect the traffic of each VPN between the device and its peer. When the number of neighbors of a device and the number of VPNs increases, the number of IPsec tunnels also increases considerably. This results in the need for a large number of SAs, which exceeds the device's capacity. This document proposes a method for different VPNs to share the use of a single IPsec tunnel, which can greatly reduce the number of SAs required in a multi-VPN scenario. | |||||||||||||
| draft-head-rift-auto-is-is-00.txt | ||||||||||||||
| RIFT Auto-IS-IS | ||||||||||||||
|
This document specifies procedures where RIFT can automatically provision IS-IS topologies by leveraging its native no-touch ZTP architecture. | |||||||||||||
| draft-hegde-lsr-ospf-better-idbx-04.txt | ||||||||||||||
| Improved OSPF Database Exchange Procedure | ||||||||||||||
|
When an OSPF router undergoes restart, previous instances of LSAs belonging to that router may remain in the databases of other routers in the OSPF domain until such LSAs are aged out. Hence, when the restarting router joins the network again, neighboring routers re- establish adjacencies while the restarting router is still bringing- up its interfaces and adjacencies and generates LSAs with sequence numbers that may be lower than the stale LSAs. Such stale LSAs may be interpreted as bi-directional connectivity before the initial database exchanges are finished and genuine bi-directional LSA connectivity exists. Such incorrect interpretation may lead to, among other things, transient traffic packet drops. This document suggests improvements in the OSPF database exchange process to prevent such problems due to stale LSA utilization. The solution does not preclude changes in the existing standard but presents an extension that will prevent this scenario. | |||||||||||||
| draft-hegdearavind-idr-bgp-ls-flex-algo-ext-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-heiwin-intarea-reverse-traceroute-stateless-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hendrickson-pp-attesterissuer-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hmntsharma-bmp-over-tls-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hoehlhubmer-https-addon-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hoehrmann-cp-collation-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hoffman-deleg-roles-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hohendorf-secure-sctp-38.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-homburg-deleg-incremental-deleg-00.txt | ||||||||||||||
| Incrementally Deployable Extensible Delegation for DNS | ||||||||||||||
|
This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with SVCB 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. The mechanism inherits extensibility from SVCB. 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. | |||||||||||||
| draft-hong-icn-metaverse-interoperability-00.txt | ||||||||||||||
| ICN Challenges for Metaverse Platform Interoperability | ||||||||||||||
|
This document explores the potential of Information-Centric Networking (ICN) to enhance interoperability between metaverse platforms. ICN's content-centric approach, in-network caching, and inherent security features can address key challenges such as scalability, low-latency performance, data ownership, and standardization needs. It also identifies these challenges and proposes solutions to optimize data sharing, enable efficient content distribution, and enforce secure access controls. | |||||||||||||
| draft-hong-nmrg-ai-deploy-07.txt | ||||||||||||||
| Considerations of network/system for AI services | ||||||||||||||
|
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. | |||||||||||||
| draft-hou-rtgwg-satellite-ground-routing-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hs-rtgwg-wan-lossless-framework-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hs-rtgwg-wan-lossless-uc-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hsyang-avtcore-rtp-vdmc-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-http2-aes256-00.txt | ||||||||||||||
| HTTP/2 AES-256 | ||||||||||||||
|
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to http/2. | |||||||||||||
| draft-hu-bfd-network-device-authentication-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hu-ipsecme-pqt-hybrid-auth-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hu-lsr-igp-link-mtu-03.txt | ||||||||||||||
| IGP Extensions for Link MTU | ||||||||||||||
|
Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths which are called segments. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS and OSPF extensions about the Path MTU that need to be used on SR. Here, the term "OSPF" means both OSPFv2 and OSPFv3. | |||||||||||||
| draft-hu-network-element-tsm-yang-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hu-opsawg-network-element-tsm-yang-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hu-opsawg-sec-config-yang-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-huang-detnet-rdi-02.txt | ||||||||||||||
| BFD Extension for DetNet Remote Defect Indication (RDI) | ||||||||||||||
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. | |||||||||||||
| draft-huang-rtgwg-standalone-sid-framework-00.txt | ||||||||||||||
| L3 Standalone Service ID Framework | ||||||||||||||
|
In the scenarios of both client to service and service to service interconnections, the host-oriented addressing mechanism turns out to be ineffective, and employment of a standalone service ID in routing network could facilitate the fine-grained interfaces of underlay networking capabilities, as well as cross connections among services residing at multiple sites. | |||||||||||||
| draft-huang-rtgwg-us-standalone-sid-01.txt | ||||||||||||||
| Use Cases-Standalone Service ID in Routing Network | ||||||||||||||
|
More and more emerging applications have raised the demand for establishing networking connections anywhere and anytime, alongside the availability of highly distributive any-cloud services. Such a demand motivates the need to efficiently interconnect heterogeneous entities, e.g., different domains of network and cloud owned by different providers to reduce cost, e.g., overheads and end-to-end latency, while ensuring the overall performance satisfies the requirements of the applications. Considering that different network domains and cloud providers may adopt different types of technologies, the key to interconnection and efficient coordination is to employ a unified interface that can be understood by heterogeneous parties, which could derive the consistent requirements of the same service and treat the service traffic appropriately by their proprietary policies and technologies. This document provides use cases and problem statements from two main Internet traffic categories: one is the traditional north-south traffic which is defined from clients to entities (such as servers or DCs), and the other is east-west traffic, which refers to traffic between entities (such as inter-server or inter- service).Furthermore,the requirements for a standalone Service ID are also detailed in this document. | |||||||||||||
| draft-huang-savnet-sav-table-08.txt | ||||||||||||||
| General Source Address Validation Capabilities | ||||||||||||||
|
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. | |||||||||||||
| draft-huigens-openpgp-signature-salt-notation-00.txt | ||||||||||||||
| OpenPGP Signature Salt Notation | ||||||||||||||
|
This document defines the "salt" Notation Name for OpenPGP version 4 signatures. This can be used to salt version 4 signatures in a backwards-compatible way. | |||||||||||||
| draft-huitema-ccwg-bbr-realtime-00.txt | ||||||||||||||
| BBR Improvements for Real-Time connections | ||||||||||||||
|
We are studying the transmission of real-time Media over QUIC. There are two priorities: maintain low transmission delays by avoiding building queues, and use the available network capacity to provide the best possible experience. We found through experiments that while the BBR algorithm generally allow us to correctly and timely assess network capacity, we still see "glitches" in specific conditions, in particular when using wireless networks. We analyze these issues and propose small changes in the BBR algorithm that could improve the quality of experience delivered by the real-time media application. | |||||||||||||
| draft-huque-dnsop-keytags-00.txt | ||||||||||||||
| Collision Free Keytags for DNSSEC | ||||||||||||||
|
DNSSEC employs a Key Tag field in the RRSIG and DS resource records in order to efficiently identify the key that produced a DNSSEC signature and the key that should be used as secure entry point into a delegated zone. The Key Tag was not intended to be a unique identifier. Key tag collisions can occur in practice for keys in the same zone, though they are relatively rare in normal operation. Colliding key tags impose additional work on a validating resolver, which then has to check signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they open up resolvers to computational denial of service attacks by adversaries deploying specially crafted zones with many intentionally colliding key tags. This document specifies updates to the DNSSEC protocol and the process of key generation to avoid colliding keys and enforce the uniqueness of key tags. | |||||||||||||
| draft-huque-dnsop-multi-alg-rules-04.txt | ||||||||||||||
| Multiple Algorithm Rules in DNSSEC | ||||||||||||||
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. | |||||||||||||
| draft-hy-srv6ops-sfc-in-cloud-uc-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hz-ippm-cei-02.txt | ||||||||||||||
| Customer Experience Index for Evaluating Network Quality for Cloud Applications | ||||||||||||||
|
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. | |||||||||||||
| draft-iab-ai-control-report-00.txt | ||||||||||||||
| IAB AI-CONTROL Workshop Report | ||||||||||||||
|
The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work. | |||||||||||||
| draft-iab-bias-workshop-report-02.txt | ||||||||||||||
| IAB Barriers to Internet Access of Services (BIAS) Workshop Report | ||||||||||||||
|
The "Barriers for Internet Access of Services (BIAS)" workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role of community networks in Internet Access of Services; reports and comments on the observed digital divide; and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussion and serves as a reference for reports on the current barriers to Internet Access. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. | |||||||||||||
| draft-iana-7120bis-00.txt | ||||||||||||||
| Early IANA Code Point Allocation for IETF Stream Internet-Drafts | ||||||||||||||
|
This memo describes the requirements for securing IANA code point assignments before RFC publication. In particular, it describes the "early allocation" process that allows for temporary but renewable allocations from registries that would ordinarily require an IESG- approved Internet-Draft: namely, registries maintained in accordance with the "Standards Action," "IETF Review," "RFC Required," and, in some cases, "Specification Required" policies. This process can be used when code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication. The procedures in this document are intended to apply only to IETF Stream documents. This document obsoletes RFC 7120. | |||||||||||||
| draft-icann-registrar-interfaces-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-6lo-nd-gaao-01.txt | ||||||||||||||
| Generic Address Assignment Option for 6LowPAN Neighbor Discovery | ||||||||||||||
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks, enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LowPAN deployment. | |||||||||||||
| draft-ietf-6lo-owc-02.txt | ||||||||||||||
| Transmission of 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 how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| draft-ietf-6lo-path-aware-semantic-addressing-09.txt | ||||||||||||||
| Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks | ||||||||||||||
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables IP packet stateless forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is static, the location of the nodes is fixed, and the connection between the nodes is also rather stable. This specifications describes the PASA architecture, along with PASA address allocation, forwarding mechanism, header format design, and IPv6 interconnection support. | |||||||||||||
| draft-ietf-6lo-prefix-registration-06.txt | ||||||||||||||
| IPv6 Neighbor Discovery Prefix Registration | ||||||||||||||
|
This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN extensions (RFC8505, RFC8928, RFC7400) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration also provides a protocol-independent interface for the node to request neighbor router(s) to redistribute the prefix to the larger routing domain using their specific routing protocols. This document extends RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the registered prefix in RPL. | |||||||||||||
| draft-ietf-6lo-schc-15dot4-07.txt | ||||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | ||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | |||||||||||||
| draft-ietf-6man-addr-assign-02.txt | ||||||||||||||
| Clarification of IPv6 Address Assignment Policy | ||||||||||||||
|
This document specifies the approval process for changes to the IPv6 Address Space registry. It also updates RFC 7249. 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-ietf-6man-addr-assign/. Discussion of this document takes place on the 6MAN Working Group mailing list (mailto:ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/. Subscribe at https://www.ietf.org/mailman/listinfo/ipv6/. | |||||||||||||
| draft-ietf-6man-deprecate-router-alert-03.txt | ||||||||||||||
| Deprecation Of The IPv6 Router Alert Option | ||||||||||||||
|
This document deprecates the IPv6 Router Alert Option. Protocols that use the Router Alert Option may continue to do so, even in future versions. However, protocols that are standardized in the future must not use the Router Alert Option. This document obsoletes RFC 2711. | |||||||||||||
| draft-ietf-6man-eh-limits-18.txt | ||||||||||||||
| Limits on Sending and Processing IPv6 Extension Headers | ||||||||||||||
|
This document defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. Limits are pragmatic to facilitate interoperability amongst hosts and routers, thereby increasing the deployability of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. | |||||||||||||
| draft-ietf-6man-enhanced-vpn-vtn-id-09.txt | ||||||||||||||
| Carrying Network Resource (NR) related Information in IPv6 Extension Header | ||||||||||||||
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet are used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along a path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can also be generalized for other network resource semantics and functions. | |||||||||||||
| draft-ietf-6man-icmpv6-ioam-conf-state-07.txt | ||||||||||||||
| IPv6 Query for Enabled In-situ OAM Capabilities | ||||||||||||||
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. | |||||||||||||
| draft-ietf-6man-ipv6-over-wireless-07.txt | ||||||||||||||
| Architecture and Framework for IPv6 over Non-Broadcast Access | ||||||||||||||
|
This document presents an architecture and framework for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. | |||||||||||||
| draft-ietf-6man-pio-pflag-12.txt | ||||||||||||||
| Signaling DHCPv6 Prefix per Client Availability to Hosts | ||||||||||||||
|
This document defines a "P" flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that clients use the RFC9663 deployment model instead of using individual adresses in the on-link prefix assigned using Stateless Address Autoconfiguration (SLAAC) or DHCPv6 address assignment. This document updates RFC4862 to indicate that the Autonomous flag in a PIO needs to be ignored if the PIO has the P flag set. It also updates RFC4861 to specify that the P flag indicates DHCPv6 Prefix Delegation support for clients. | |||||||||||||
| draft-ietf-6man-rfc6724-update-15.txt | ||||||||||||||
| Prioritizing known-local IPv6 ULAs through address selection policy | ||||||||||||||
|
This document draws on several years of operational experience to update RFC 6724, defining the concept of "known-local" ULA prefixes that enable ULA-to-ULA communications within fd00::/8 to become preferred over both IPv4-IPv4 and GUA-to-GUA for local use. The document defines the means by which nodes can both identify and insert such prefixes into their address selection policy table. It also clarifies the mandatory, unconditional requirement for support for Rule 5.5 and demotes the preference for 6to4 addresses. These changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios, and makes preference for IPv6 over IPv4 consistent in local site networks for both ULA and GUA prefixes. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. | |||||||||||||
| draft-ietf-6man-slaac-renum-08.txt | ||||||||||||||
| Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events | ||||||||||||||
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8106. | |||||||||||||
| draft-ietf-6man-snac-router-ra-flag-03.txt | ||||||||||||||
| SNAC Router Flag in ICMPv6 Router Advertisement Messages | ||||||||||||||
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices. | |||||||||||||
| draft-ietf-6man-vpn-dest-opt-01.txt | ||||||||||||||
| The IPv6 VPN Service Destination Option | ||||||||||||||
|
This document describes an experiment in which VPN service information for both layer 2 and layer 3 VPNs is encoded in a new IPv6 Destination Option. The new IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment. | |||||||||||||
| draft-ietf-6man-zone-ui-05.txt | ||||||||||||||
| Entering IPv6 Zone Identifiers in User Interfaces | ||||||||||||||
|
This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874 and updates RFC 4007, RFC 7622 and RFC 8089. Discussion Venue This note is to be removed before publishing as an RFC. Discussion of this document takes place on the 6MAN mailing list (ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/ (https://mailarchive.ietf.org/arch/browse/ipv6/). | |||||||||||||
| draft-ietf-ace-coap-est-oscore-06.txt | ||||||||||||||
| Protecting EST Payloads with OSCORE | ||||||||||||||
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. | |||||||||||||
| draft-ietf-ace-edhoc-oscore-profile-06.txt | ||||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. | |||||||||||||
| draft-ietf-ace-group-oscore-profile-03.txt | ||||||||||||||
| The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the client's public key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. | |||||||||||||
| draft-ietf-ace-key-groupcomm-oscore-16.txt | ||||||||||||||
| Key Management for OSCORE Groups in ACE | ||||||||||||||
|
This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. | |||||||||||||
| draft-ietf-ace-oscore-gm-admin-12.txt | ||||||||||||||
| Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession, and server authentication. | |||||||||||||
| draft-ietf-ace-oscore-gm-admin-coral-02.txt | ||||||||||||||
| Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. | |||||||||||||
| draft-ietf-ace-pubsub-profile-10.txt | ||||||||||||||
| Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. | |||||||||||||
| draft-ietf-ace-revoked-token-notification-09.txt | ||||||||||||||
| Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers to access a Token Revocation List on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and resource servers. | |||||||||||||
| draft-ietf-ace-wg-coap-eap-12.txt | ||||||||||||||
| EAP-based Authentication Service for CoAP | ||||||||||||||
|
This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. | |||||||||||||
| draft-ietf-ace-workflow-and-params-03.txt | ||||||||||||||
| Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the authorization server can use for uploading an access token to a resource server on behalf of the client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the authorization server. Third, it defines a method for the ACE framework to enforce bidirectional access control by means of a single access token. Fourth, it amends two of the requirements on profiles of the framework. Finally, it deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads. For such error responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles of ACE defined in RFC 9202, RFC 9203, and RFC 9431. | |||||||||||||
| draft-ietf-acme-ari-07.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension | ||||||||||||||
|
This document specifies how an ACME server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods. | |||||||||||||
| draft-ietf-acme-client-09.txt | ||||||||||||||
| ACME End User Client and Code Signing Certificates | ||||||||||||||
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support end user client, device client, and code signing certificates. | |||||||||||||
| draft-ietf-acme-dns-account-label-00.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge | ||||||||||||||
|
This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. By adding a unique label to the DNS validation record name, the dns-account-01 challenge avoids CNAME delegation conflicts inherent to the dns-01 challenge type. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. | |||||||||||||
| draft-ietf-acme-dtnnodeid-16.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension | ||||||||||||||
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". | |||||||||||||
| draft-ietf-acme-integrations-17.txt | ||||||||||||||
| ACME Integrations for Device Certificate Enrollment | ||||||||||||||
|
This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. | |||||||||||||
| draft-ietf-acme-onion-05.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names | ||||||||||||||
|
The document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor hidden services (".onion" Special-Use Domain Names). Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/AS207960/acme-onion. The project website and a reference implementation can be found at https://acmeforonions.org. | |||||||||||||
| draft-ietf-add-encrypted-dns-server-redirection-01.txt | ||||||||||||||
| Encrypted DNS Server Redirection | ||||||||||||||
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. | |||||||||||||
| draft-ietf-add-split-horizon-authority-14.txt | ||||||||||||||
| Establishing Local DNS Authority in Validated Split-Horizon Environments | ||||||||||||||
|
When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver. DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains. | |||||||||||||
| draft-ietf-alto-oam-yang-17.txt | ||||||||||||||
| YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol | ||||||||||||||
|
This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. | |||||||||||||
| draft-ietf-anima-brski-ae-13.txt | ||||||||||||||
| BRSKI-AE: Alternative Enrollment Protocols in BRSKI | ||||||||||||||
|
This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative Enrollment). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of EST. It supports certificate enrollment protocols, such as CMP, that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments. | |||||||||||||
| draft-ietf-anima-brski-cloud-11.txt | ||||||||||||||
| BRSKI Cloud Registrar | ||||||||||||||
|
Bootstrapping Remote Secure Key Infrastructures defines how to onboard a device securely into an operator maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. This document extends the new device behavior so that if no local infrastructure is available, such as in a home or remote office, that the device can use a well-defined "call-home" mechanism to find the operator maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator maintained infrastructure. The Cloud Registrar enables discovery of the operator maintained infrastructure, and may enable establishment of trust with operator maintained infrastructure that does not support BRSKI mechanisms. | |||||||||||||
| draft-ietf-anima-brski-discovery-05.txt | ||||||||||||||
| BRSKI discovery and variations | ||||||||||||||
|
This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators, especially in the face of variations in the protocols that can introduce non-interoperability when not equally supported by both responder and initiator. | |||||||||||||
| draft-ietf-anima-brski-prm-15.txt | ||||||||||||||
| BRSKI with Pledge in Responder Mode (BRSKI-PRM) | ||||||||||||||
|
This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the Key Infrastructure (e.g., domain CA). | |||||||||||||
| draft-ietf-anima-constrained-voucher-25.txt | ||||||||||||||
| Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) | ||||||||||||||
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. | |||||||||||||
| draft-ietf-anima-grasp-distribution-12.txt | ||||||||||||||
| Information Distribution over GRASP | ||||||||||||||
|
This document specifies experimental extensions to the GRASP protocol to enable information distribution capabilities. The extension has two aspects: 1) new GRASP messages and options; 2) processing behaviors on the nodes. With these extensions, the GRASP would have following new capabilities which make it a sufficient tool for general information distribution: 1) Pub-Sub model of information processing; 2) one node can actively sending data to another, without GRASP negotiation procedures; 3) selective flooding mechanism to allow the ASAs control the flooding scope. This document updates RFC8990, the GeneRic Autonomic Signaling Protocol (GRASP)[RFC8990]. | |||||||||||||
| draft-ietf-anima-jws-voucher-14.txt | ||||||||||||||
| JWS signed Voucher Artifacts for Bootstrapping Protocols | ||||||||||||||
|
I-D.ietf-anima-rfc8366bis defines a digital artifact (known as a voucher) as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS. In addition to specifying the format, the "application/voucher- jws+json" media type is registered and examples are provided. | |||||||||||||
| draft-ietf-anima-rfc8366bis-12.txt | ||||||||||||||
| A Voucher Artifact for Bootstrapping Protocols | ||||||||||||||
|
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. | |||||||||||||
| draft-ietf-asdf-nipc-03.txt | ||||||||||||||
| An Application Layer Interface for Non-IP device control (NIPC) | ||||||||||||||
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices. The described interface is extensible. This memo initially describes Bluetooth Low Energy and Zigbee as they are the most commonly deployed. | |||||||||||||
| draft-ietf-asdf-sdf-18.txt | ||||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things | ||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. // The present revision (-18) adds security considerations, a few // editorial cleanups, discusses JSON pointer encodings, and adds // sockets to the CDDL for easier future extension. | |||||||||||||
| draft-ietf-avtcore-hevc-webrtc-06.txt | ||||||||||||||
| H.265 Profile for WebRTC | ||||||||||||||
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, similar guidance is needed for browsers considering support for the H.265 codec, whose RTP payload format is defined in RFC 7798. | |||||||||||||
| draft-ietf-avtcore-rtcp-green-metadata-04.txt | ||||||||||||||
| RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution | ||||||||||||||
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. | |||||||||||||
| draft-ietf-avtcore-rtp-haptics-01.txt | ||||||||||||||
| RTP Payload for Haptics | ||||||||||||||
|
This memo describes an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS(MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. | |||||||||||||
| draft-ietf-avtcore-rtp-j2k-scl-04.txt | ||||||||||||||
| RTP Payload Format for sub-codestream latency JPEG 2000 streaming | ||||||||||||||
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given codestream can be emitted before the entire codestream is available. | |||||||||||||
| draft-ietf-avtcore-rtp-over-quic-12.txt | ||||||||||||||
| RTP over QUIC (RoQ) | ||||||||||||||
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. | |||||||||||||
| draft-ietf-avtcore-rtp-payload-registry-05.txt | ||||||||||||||
| Closing the RTP Payload Format Media Types IANA Registry | ||||||||||||||
|
A number of authors of RTP Payload Formats and the WG process have failed to ensure that the media types for RTP payload formats is registred in the IANA registry "RTP Payload Formats Media Types" as recommended by RFC 8088. To simplify the process and rely only on the media types registry this document closes the RTP payload specific registry. In addition it updates the instruction to payload format authors in RFC 8088 to reflect this change. | |||||||||||||
| draft-ietf-avtcore-rtp-v3c-07.txt | ||||||||||||||
| RTP Payload Format for Visual Volumetric Video-based Coding (V3C) | ||||||||||||||
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. | |||||||||||||
| draft-ietf-avtext-framemarking-16.txt | ||||||||||||||
| Video Frame Marking RTP Header Extension | ||||||||||||||
|
This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec- specific information. | |||||||||||||
| draft-ietf-avtext-lrr-07.txt | ||||||||||||||
| The Layer Refresh Request (LRR) RTCP Feedback Message | ||||||||||||||
|
This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. | |||||||||||||
| draft-ietf-bess-bgp-multicast-controller-13.txt | ||||||||||||||
| Controller Based BGP Multicast Signaling | ||||||||||||||
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. | |||||||||||||
| draft-ietf-bess-bgp-sdwan-usage-25.txt | ||||||||||||||
| BGP Usage for SD-WAN Overlay Networks | ||||||||||||||
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. | |||||||||||||
| draft-ietf-bess-bgp-srv6-args-03.txt | ||||||||||||||
| SRv6 Argument Signaling for BGP Services | ||||||||||||||
|
RFC9252 defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 SID advertisements for BGP Service routes associated with SRv6 Endpoint Behaviors that support arguments. | |||||||||||||
| draft-ietf-bess-evpn-bfd-08.txt | ||||||||||||||
| EVPN Network Layer Fault Management | ||||||||||||||
|
This document specifies proactive, in-band network layer OAM (RFC 9062) mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN, RFC 7432bis) network. The mechanisms specified in this document use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol. | |||||||||||||
| draft-ietf-bess-evpn-dpath-01.txt | ||||||||||||||
| Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks | ||||||||||||||
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. | |||||||||||||
| draft-ietf-bess-evpn-fast-df-recovery-12.txt | ||||||||||||||
| Fast Recovery for EVPN Designated Forwarder Election | ||||||||||||||
|
The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for Designated Forwarder election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group. | |||||||||||||
| draft-ietf-bess-evpn-geneve-08.txt | ||||||||||||||
| EVPN control plane for Geneve | ||||||||||||||
|
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by Network Virtualization Edges (NVEs) to express Geneve tunnel option TLV(s) supported in the transmission and/or reception of Geneve encapsulated data packets. | |||||||||||||
| draft-ietf-bess-evpn-ip-aliasing-02.txt | ||||||||||||||
| EVPN Support for L3 Fast Convergence and Aliasing/Backup Path | ||||||||||||||
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. | |||||||||||||
| draft-ietf-bess-evpn-ipvpn-interworking-11.txt | ||||||||||||||
| EVPN Interworking with IPVPN | ||||||||||||||
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. | |||||||||||||
| draft-ietf-bess-evpn-irb-extended-mobility-21.txt | ||||||||||||||
| Extended Mobility Procedures for EVPN-IRB | ||||||||||||||
|
This document specifies extensions to Ethernet VPN (EVPN) Integrated Routing and Bridging (IRB) procedures specified in RFC7432 and RFC9135 to enhance the mobility mechanisms for EVPN-IRB based networks. The proposed extensions improve the handling of host mobility and duplicate address detection in EVPN-IRB networks to cover a broader set of scenarios where a host's unicast IP address to MAC address bindings may change across moves. These enhancements address limitations in the existing EVPN-IRB mobility procedures by providing more efficient and scalable solutions. The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility. NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six authors which is above the required limit of five. Given significant and active contributions to the draft from all six authors over the course of six years, we would like to request IESG to allow publication with six authors. Specifically, the three Cisco authors are the original inventors of these procedures and contributed heavily to rev 0 draft, most of which is still intact. AT&T is also a key contributor towards defining the use cases that this document addresses as well as the proposed solution. Authors from Nokia and Juniper have further contributed to revisions and discussions steadily over last six years to enable respective implementations and a wider adoption. | |||||||||||||
| draft-ietf-bess-evpn-mh-pa-13.txt | ||||||||||||||
| EVPN Port-Active Redundancy Mode | ||||||||||||||
|
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load-balancing. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'. | |||||||||||||
| draft-ietf-bess-evpn-mh-split-horizon-11.txt | ||||||||||||||
| BGP EVPN Multi-Homing Extensions for Split Horizon Filtering | ||||||||||||||
|
Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The multi-homing procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multi-homing Split Horizon procedures designed to prevent looped frames on multi-homed Customer Edge (CE) devices: the ESI Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon is applied to MPLS-based tunnels, such as MPLSoUDP, while the Local Bias procedure is used for other tunnels, such as VXLAN. Current specifications do not allow operators to choose which Split Horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates the EVPN multi-homing procedures described in RFC 8365 and RFC 7432, enabling operators to select the Split Horizon procedure that meets their specific requirements. | |||||||||||||
| draft-ietf-bess-evpn-mvpn-seamless-interop-07.txt | ||||||||||||||
| Seamless Multicast Interoperability between EVPN and MVPN PEs | ||||||||||||||
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. | |||||||||||||
| draft-ietf-bess-evpn-pref-df-13.txt | ||||||||||||||
| Preference-based EVPN DF Election | ||||||||||||||
|
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single- active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user- controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. This document updates RFC8584 by modifying the definition of the DF Election Extended Community. | |||||||||||||
| draft-ietf-bess-evpn-redundant-mcast-source-13.txt | ||||||||||||||
| Multicast Source Redundancy in EVPN Networks | ||||||||||||||
|
In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic replication and delivery play a crucial role in enabling efficient and scalable Layer 2 and Layer 3 services. A common deployment scenario involves redundant multicast sources that ensure high availability and resiliency. However, the presence of redundant sources can lead to duplicate IP multicast traffic in the network, causing inefficiencies and increased overhead. This document specifies extensions to the EVPN multicast procedures that allow for the suppression of duplicate IP multicast traffic from redundant sources. The proposed mechanisms enhance EVPN's capability to deliver multicast traffic efficiently while maintaining high availability. These extensions are applicable to various EVPN deployment scenarios and provide guidelines to ensure consistent and predictable behavior across diverse network topologies. | |||||||||||||
| draft-ietf-bess-evpn-unequal-lb-24.txt | ||||||||||||||
| Weighted Multi-Path Procedures for EVPN Multi-Homing | ||||||||||||||
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. | |||||||||||||
| draft-ietf-bess-evpn-virtual-eth-segment-19.txt | ||||||||||||||
| EVPN Virtual Ethernet Segment | ||||||||||||||
|
Ethernet VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multi-homing capabilities. Specifically, they support Single-Active and All- Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multi-homed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an Ethernet Segment by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or other entities, including MPLS Label Switched Paths (LSPs) or Pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vES). This draft list the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN. | |||||||||||||
| draft-ietf-bess-evpn-vpws-fxc-12.txt | ||||||||||||||
| EVPN VPWS Flexible Cross-Connect Service | ||||||||||||||
|
This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as EVPN VPWS flexible cross-connect service. This document specifies a solution based on extensions to EVPN VPWS(RFC8214) which in turn is based on extensions to EVPN (RFC7432). Therefore, a thorough understanding of RFC7432 and RFC8214 are prerequisites for this document. | |||||||||||||
| draft-ietf-bess-evpn-vpws-seamless-01.txt | ||||||||||||||
| EVPN-VPWS Seamless Integration with L2VPN VPWS | ||||||||||||||
|
This document presents a solution for migrating L2VPN Virtual Private Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) services. The solution allows the coexistence of EVPN and L2VPN services under the same point-to-point VPN instance. By using this seamless integration solution, a service provider can introduce EVPN into their existing L2VPN network or migrate from an existing L2VPN based network to EVPN. The migration may be done per pseudowire or per flexible-crossconnect (FXC) service basis. This document specifies control-plane and forwarding behaviors. | |||||||||||||
| draft-ietf-bess-extended-evpn-optimized-ir-07.txt | ||||||||||||||
| Extended Procedures for EVPN Optimized Ingress Replication | ||||||||||||||
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. | |||||||||||||
| draft-ietf-bess-mvpn-evpn-sr-p2mp-11.txt | ||||||||||||||
| Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication | ||||||||||||||
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. | |||||||||||||
| draft-ietf-bess-rfc7432bis-10.txt | ||||||||||||||
| BGP MPLS-Based Ethernet VPN | ||||||||||||||
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates RFC8214 (Virtual Private Wire Service Support in Ethernet VPN). | |||||||||||||
| draft-ietf-bess-secure-evpn-02.txt | ||||||||||||||
| Secure EVPN | ||||||||||||||
|
The applications of EVPN-based solutions (BGP MPLS-based Ethernet VPN and Network Virtualization Overlay Solution using EVPN) have become pervasive in Data Center, Service Provider, and Enterprise segments. It is being used for fabric overlays and inter-site connectivity in the Data Center market segment, for Layer-2, Layer-3, and IRB VPN services in the Service Provider market segment, and for fabric overlay and WAN connectivity in Enterprise networks. For Data Center and Enterprise applications, there is a need to provide inter-site and WAN connectivity over public Internet in a secured manner with same level of privacy, integrity, and authentication for tenant's traffic as IPsec tunneling using IKEv2. This document presents a solution where BGP point-to-multipoint signaling is leveraged for key and policy exchange among PE devices to create private pair-wise IPsec Security Associations without IKEv2 point-to-point signaling or any other direct peer-to-peer session establishment messages. | |||||||||||||
| draft-ietf-bess-v4-v6-pe-all-safi-02.txt | ||||||||||||||
| IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI | ||||||||||||||
|
As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the four major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. | |||||||||||||
| draft-ietf-bess-weighted-hrw-01.txt | ||||||||||||||
| Weighted HRW and its applications | ||||||||||||||
|
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. | |||||||||||||
| draft-ietf-bfd-large-packets-14.txt | ||||||||||||||
| BFD Encapsulated in Large Packets | ||||||||||||||
|
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document specifies how to implement such a mechanism using BFD in Asynchronous mode. YANG modules for managing this mechanism are also defined in this document. These YANG modules augment the existing BFD YANG modules defined in RFC 9314. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). | |||||||||||||
| draft-ietf-bfd-optimizing-authentication-21.txt | ||||||||||||||
| Optimizing BFD Authentication | ||||||||||||||
|
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. | |||||||||||||
| draft-ietf-bfd-secure-sequence-numbers-18.txt | ||||||||||||||
| Meticulous Keyed ISAAC for BFD Authentication | ||||||||||||||
|
This document describes a new BFD Authentication mechanism, Meticulous Keyed ISAAC. This mechanism can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used as an authenticated signal to maintain a session in the the "Up" state. | |||||||||||||
| draft-ietf-bfd-stability-16.txt | ||||||||||||||
| BFD Stability | ||||||||||||||
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD packet loss. | |||||||||||||
| draft-ietf-bfd-unaffiliated-echo-14.txt | ||||||||||||||
| Unaffiliated Bidirectional Forwarding Detection (BFD) Echo | ||||||||||||||
|
This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency. This document updates RFC 5880 by defining a new Unaffiliated BFD Echo mechanism. | |||||||||||||
| draft-ietf-bier-bfd-07.txt | ||||||||||||||
| BIER BFD | ||||||||||||||
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. | |||||||||||||
| draft-ietf-bier-bgp-ls-bier-ext-19.txt | ||||||||||||||
| BGP Link-State extensions for BIER | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables 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 the BIER informations. | |||||||||||||
| draft-ietf-bier-bier-yang-09.txt | ||||||||||||||
| YANG Data Model for BIER Protocol | ||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage devices supporting Bit Index Explicit Replication"(BIER). The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-bier-bierin6-10.txt | ||||||||||||||
| Supporting BIER in IPv6 Networks (BIERin6) | ||||||||||||||
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. | |||||||||||||
| draft-ietf-bier-frr-04.txt | ||||||||||||||
| BIER Fast ReRoute | ||||||||||||||
|
BIER is a scalable multicast overlay that utilizes a routing underlay, e.g., IP, to build up its Bit Index Forwarding Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-FRR). It protects BIER traffic after detecting the failure of a link or node in the core of a BIER domain until affected BIFT entries are recomputed after reconvergence of the routing underlay. BIER-FRR is applied locally at the point of local repair (PLR) and does not introduce any per-flow state. The document specifies nomenclature for BIER-FRR and gives examples for its integration in BIER forwarding. Furthermore, it presents operation modes for BIER-FRR. Link and node protection may be chosen as protection level. Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based BIER-FRR are defined and compared. | |||||||||||||
| draft-ietf-bier-idr-extensions-19.txt | ||||||||||||||
| BGP Extensions for BIER | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is a multicast forwarding architecture that doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain per-tree multicast states. Some BIER-specific information and state, which are only in proportion to the number of BIER routers but not per- tree, do need to be advertised, calculated, and maintained. This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisements. | |||||||||||||
| draft-ietf-bier-oam-requirements-16.txt | ||||||||||||||
| Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer | ||||||||||||||
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. | |||||||||||||
| draft-ietf-bier-path-mtu-discovery-17.txt | ||||||||||||||
| Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer | ||||||||||||||
|
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. | |||||||||||||
| draft-ietf-bier-php-16.txt | ||||||||||||||
| BIER Penultimate Hop Popping | ||||||||||||||
|
This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks. | |||||||||||||
| draft-ietf-bier-ping-15.txt | ||||||||||||||
| BIER Ping and Trace | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast-related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. | |||||||||||||
| draft-ietf-bier-pmmm-oam-16.txt | ||||||||||||||
| Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer | ||||||||||||||
|
This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. | |||||||||||||
| draft-ietf-bier-prefix-redistribute-07.txt | ||||||||||||||
| BIER Prefix Redistribute | ||||||||||||||
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. | |||||||||||||
| draft-ietf-bier-source-protection-07.txt | ||||||||||||||
| BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover | ||||||||||||||
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. | |||||||||||||
| draft-ietf-bier-te-yang-07.txt | ||||||||||||||
| A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) | ||||||||||||||
|
This document defines a YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. | |||||||||||||
| draft-ietf-bier-tether-08.txt | ||||||||||||||
| Tethering A BIER Router To A BIER Incapable Router | ||||||||||||||
|
This document specifies optional enhancements to optimize the support of Bit Index Explicit Replication (BIER) incapable routers in a BIER domain by attaching (tethering) a BIER router to a BIER incapable router, including procedures and ISIS/OSPF/BGP signaling extensions. | |||||||||||||
| draft-ietf-bmwg-benchmarking-stateful-09.txt | ||||||||||||||
| Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers | ||||||||||||||
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. | |||||||||||||
| draft-ietf-bmwg-containerized-infra-03.txt | ||||||||||||||
| Considerations for Benchmarking Network Performance in Containerized Infrastructures | ||||||||||||||
|
Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resources allocation and network technologies are specified for containerized network functions. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. | |||||||||||||
| draft-ietf-bmwg-mlrsearch-08.txt | ||||||||||||||
| Multiple Loss Ratio Search | ||||||||||||||
|
This document proposes extensions to [RFC2544] throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and enhance result repeatability and comparability. The primary reason for extending [RFC2544] is to address the challenges and requirements presented by the evaluation and testing the data planes of software-based networking systems. To give users more freedom, MLRsearch provides additional configuration options such as allowing multiple short trials per load instead of one large trial, tolerating a certain percentage of trial results with higher loss, and supporting the search for multiple goals with varying loss ratios. | |||||||||||||
| draft-ietf-bmwg-network-tester-cfg-05.txt | ||||||||||||||
| A YANG Data Model for Network Tester Management | ||||||||||||||
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. | |||||||||||||
| draft-ietf-bmwg-sr-bench-meth-02.txt | ||||||||||||||
| Benchmarking Methodology for Segment Routing | ||||||||||||||
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). It builds upon RFC 2544, RFC 5180, RFC 5695 and RFC 8402. | |||||||||||||
| draft-ietf-calext-ical-tasks-11.txt | ||||||||||||||
| Task Extensions to iCalendar | ||||||||||||||
|
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has been seen as the poor relation of VEVENT - useful only for personal reminders and to- do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. | |||||||||||||
| draft-ietf-calext-itip-participants-00.txt | ||||||||||||||
| iTip using PARTICIPANT only | ||||||||||||||
|
This specification defines updates to RFC5546 iTip which allow scheduling using the "PARTICIPANT" calendar components specified in RFC9073. New properties are also defined for use within the "PARTICIPANT" calendar component. | |||||||||||||
| draft-ietf-calext-jscalendar-icalendar-09.txt | ||||||||||||||
| JSCalendar: Converting from and to iCalendar | ||||||||||||||
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. Note This note is to be removed before publishing as an RFC. This document is unfinished. The term TBD stands for any unknown item. | |||||||||||||
| draft-ietf-calext-subscription-upgrade-12.txt | ||||||||||||||
| Calendar subscription upgrades | ||||||||||||||
|
This specification updates RFC5545 to add the value DELETED to the STATUS property. This specification also adds values to the Preferences Registry defined in RFC7240 to add the subscribe-enhanced-get and limit preferences and to the link relations directory defined in RFC8288. | |||||||||||||
| draft-ietf-calext-vpoll-07.txt | ||||||||||||||
| VPOLL: Consensus Scheduling Component for iCalendar | ||||||||||||||
|
This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. | |||||||||||||
| draft-ietf-cats-framework-04.txt | ||||||||||||||
| A Framework for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes. | |||||||||||||
| draft-ietf-cats-usecases-requirements-04.txt | ||||||||||||||
| Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
Distributed computing is a tool that service providers can use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities aids support of services such as computationally intensive and delay sensitive services. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response times. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to best meet the customer's expectations and deliver the requested service. | |||||||||||||
| draft-ietf-cbor-cddl-modules-03.txt | ||||||||||||||
| CDDL Module Structure | ||||||||||||||
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. | |||||||||||||
| draft-ietf-cbor-cddl-more-control-07.txt | ||||||||||||||
| More Control Operators for CDDL | ||||||||||||||
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (Bytes, Integers, JSON, Printf-style formatting) and for an operation on text. | |||||||||||||
| draft-ietf-cbor-cde-06.txt | ||||||||||||||
| CBOR Common Deterministic Encoding (CDE) | ||||||||||||||
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. | |||||||||||||
| draft-ietf-cbor-edn-e-ref-00.txt | ||||||||||||||
| External References to Values in CBOR Diagnostic Notation (EDN) | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. | |||||||||||||
| draft-ietf-cbor-edn-literals-14.txt | ||||||||||||||
| CBOR Extended Diagnostic Notation (EDN) | ||||||||||||||
|
The Concise Binary Object Representation (CBOR) (STD 94, 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 addition to the binary interchange format, CBOR from the outset (RFC 7049) defined a text-based "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. RFC 8610 extended this into what is known as Extended Diagnostic Notation (EDN). This document consolidates the definition of EDN, sets forth a further step of its evolution, and is intended to serve as a single reference target in specifications that use EDN. It updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It specifies an extension point for adding application-oriented extensions to the diagnostic notation. It then defines two such extensions that enhance EDN with text representations of epoch-based date/times and of IP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. The document modifies one extension originally specified in Appendix G.4 of RFC 8610 to enable further increasing usability. To facilitate tool interoperation, this document specifies a formal ABNF grammar, and it adds media types. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision -14 is intended to reflect the feedback on -13 as // discussed during IETF 121. | |||||||||||||
| draft-ietf-cbor-packed-13.txt | ||||||||||||||
| Packed CBOR | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a simple transformation of a CBOR data item into another CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // The present version (-13) is a refresh of the implementation draft // -12 with minor editorial improvements. | |||||||||||||
| draft-ietf-ccamp-actn-optical-transport-mgmt-02.txt | ||||||||||||||
| Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks | ||||||||||||||
|
Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. | |||||||||||||
| draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps-00.txt | ||||||||||||||
| Use cases,Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework | ||||||||||||||
|
This document provides general overarching guidelines for control and management of packet over optical converged networks with coherent pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on coherent pluggables. The document provides a gap analysis to solve the use cases. | |||||||||||||
| draft-ietf-ccamp-client-signal-yang-13.txt | ||||||||||||||
| A YANG Data Model for Transport Network Client Signals | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. | |||||||||||||
| draft-ietf-ccamp-dwdm-if-param-yang-11.txt | ||||||||||||||
| A YANG model to manage the optical interface parameters for an external transponder in a WDM network | ||||||||||||||
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. Is to be noted that the Transceivers can be located on the Transponders (optical layer) or on the Router (in general packet layer) in form of Pluggable modules. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | |||||||||||||
| draft-ietf-ccamp-eth-client-te-topo-yang-07.txt | ||||||||||||||
| A YANG Data Model for Ethernet TE Topology | ||||||||||||||
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. | |||||||||||||
| draft-ietf-ccamp-flexe-yang-cm-05.txt | ||||||||||||||
| YANG Data Model for FlexE Management | ||||||||||||||
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-ccamp-flexigrid-yang-17.txt | ||||||||||||||
| A YANG Data Model for Flexi-Grid Optical Networks | ||||||||||||||
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. | |||||||||||||
| draft-ietf-ccamp-l1csm-yang-26.txt | ||||||||||||||
| A YANG Data Model for L1 Connectivity Service Model (L1CSM) | ||||||||||||||
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-ccamp-layer1-types-18.txt | ||||||||||||||
| Common YANG Data Types for Layer 1 Networks | ||||||||||||||
|
This document defines a collection of common common data types, identities, and groupings in the YANG data modeling language. These derived common common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. | |||||||||||||
| draft-ietf-ccamp-optical-impairment-topology-yang-17.txt | ||||||||||||||
| A YANG Data Model for Optical Impairment-aware Topology | ||||||||||||||
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks. | |||||||||||||
| draft-ietf-ccamp-optical-path-computation-yang-04.txt | ||||||||||||||
| YANG Data Models for requesting Path Computation in WDM Optical Networks | ||||||||||||||
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | |||||||||||||
| draft-ietf-ccamp-otn-path-computation-yang-04.txt | ||||||||||||||
| A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) | ||||||||||||||
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | |||||||||||||
| draft-ietf-ccamp-otn-topo-yang-20.txt | ||||||||||||||
| A YANG Data Model for Optical Transport Network Topology | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. | |||||||||||||
| draft-ietf-ccamp-otn-tunnel-model-22.txt | ||||||||||||||
| A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths | ||||||||||||||
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. | |||||||||||||
| draft-ietf-ccamp-rfc9093-bis-12.txt | ||||||||||||||
| Common YANG Data Types for Layer 0 Networks | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. | |||||||||||||
| draft-ietf-ccamp-wdm-tunnel-yang-03.txt | ||||||||||||||
| A YANG Data Model for WDM Tunnels | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-ccamp-yang-otn-slicing-07.txt | ||||||||||||||
| Framework and Data Model for OTN Network Slicing | ||||||||||||||
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. | |||||||||||||
| draft-ietf-ccwg-bbr-01.txt | ||||||||||||||
| BBR Congestion Control | ||||||||||||||
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. | |||||||||||||
| draft-ietf-ccwg-rfc5033bis-08.txt | ||||||||||||||
| Specifying New Congestion Control Algorithms | ||||||||||||||
|
This document replaces RFC 5033, which discusses the principles and guidelines for standardzing new congestion control algorithms. It seeks to ensure that proposed congestion control algorithms operate without harm and efficiently alongside other algorithms in the global Internet. It emphasizes the need for comprehensive testing and validation to prevent adverse interactions with existing flows. This document provides a framework for the development and assessment of congestion control mechanisms, promoting stability across diverse network environments. It obsoletes RFC5033 to reflect changes in the congestion control landscape. | |||||||||||||
| draft-ietf-cdni-cache-control-metadata-02.txt | ||||||||||||||
| CDNI Cache Control Metadata | ||||||||||||||
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. | |||||||||||||
| draft-ietf-cdni-capacity-insights-extensions-12.txt | ||||||||||||||
| CDNI Capacity Capability Advertisement Extensions | ||||||||||||||
|
The Content Delivery Networks Interconnection (CDNI) Capacity Capability Advertisement Extensions define a set of additional Capability Objects that provide information about current downstream CDN (dCDN) utilization and specified usage limits to the delegating upstream CDN (uCDN) in order to inform traffic delegation decisions. This document supplements the CDNI Capability Objects, defined in RFC 8008 as part of the Footprints & Capabilities Advertisement Interface (FCI), with two additional Capability Objects: FCI.CapacityLimits and FCI.Telemetry. | |||||||||||||
| draft-ietf-cdni-ci-triggers-rfc8007bis-15.txt | ||||||||||||||
| Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition | ||||||||||||||
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition metadata or content as well as request that it invalidate or purge metadata or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. | |||||||||||||
| draft-ietf-cdni-client-access-control-metadata-00.txt | ||||||||||||||
| CDNI Client Access Control Metadata | ||||||||||||||
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. | |||||||||||||
| draft-ietf-cdni-edge-control-metadata-02.txt | ||||||||||||||
| CDNI Edge Control Metadata | ||||||||||||||
|
This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. | |||||||||||||
| draft-ietf-cdni-logging-extensions-00.txt | ||||||||||||||
| CDNI Logging Extensions | ||||||||||||||
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. | |||||||||||||
| draft-ietf-cdni-named-footprints-00.txt | ||||||||||||||
| Content Delivery Network Interconnection (CDNI) Named Footprints | ||||||||||||||
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document extends the Footprint & Capabilities Advertisement Interface (FCI) defined in RFC8008, to allow advertising of named footprint objects, that can be referenced in a consistent manner from Metadata Interface (MI), also defined in RFC8006, as well as from the FCI itself as well as additional interfaces in the Open Caching architecture. This document also supplements the CDNI Metadata Footprint Types defined in RFC8006 and modifies the CDNI operation as described in RFC7336. | |||||||||||||
| draft-ietf-cdni-protected-secrets-metadata-02.txt | ||||||||||||||
| CDNI Protected Secrets Metadata | ||||||||||||||
|
This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. | |||||||||||||
| draft-ietf-cellar-chapter-codecs-05.txt | ||||||||||||||
| Matroska Media Container Chapter Codecs Specifications | ||||||||||||||
|
This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. | |||||||||||||
| draft-ietf-cellar-codec-14.txt | ||||||||||||||
| Matroska Media Container Codec Specifications | ||||||||||||||
|
This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. | |||||||||||||
| draft-ietf-cellar-control-05.txt | ||||||||||||||
| Matroska Media Container Control Track Specifications | ||||||||||||||
|
This document defines the Control Track usage found in the Matroska container. | |||||||||||||
| draft-ietf-cellar-tags-15.txt | ||||||||||||||
| Matroska Media Container Tag Specifications | ||||||||||||||
|
This document defines the Matroska tags, namely the tag names and their respective semantic meaning. | |||||||||||||
| draft-ietf-core-cf-reg-update-01.txt | ||||||||||||||
| Update to the IANA CoAP Content-Formats Registration Procedures | ||||||||||||||
|
This document updates the registration procedures for the "CoAP Content-Formats" registry, within the "CoRE Parameters" registry group, defined in Section 12.3 of RFC7252, specifically, those regarding the First Come First Served (FCFS) portion of the registry. | |||||||||||||
| draft-ietf-core-coap-dtls-alpn-01.txt | ||||||||||||||
| ALPN ID Specification for CoAP over DTLS | ||||||||||||||
|
This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured CoAP services. | |||||||||||||
| draft-ietf-core-coap-pm-03.txt | ||||||||||||||
| Constrained Application Protocol (CoAP) Performance Measurement Option | ||||||||||||||
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. | |||||||||||||
| draft-ietf-core-coap-pubsub-15.txt | ||||||||||||||
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. | |||||||||||||
| draft-ietf-core-comi-19.txt | ||||||||||||||
| CoAP Management Interface (CORECONF) | ||||||||||||||
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. | |||||||||||||
| draft-ietf-core-conditional-attributes-10.txt | ||||||||||||||
| Conditional Attributes for Constrained RESTful Environments | ||||||||||||||
|
This specification defines Conditional Notification and Control Attributes that work with CoAP Observe (RFC7641). | |||||||||||||
| draft-ietf-core-corr-clar-01.txt | ||||||||||||||
| Constrained Application Protocol (CoAP): Corrections and Clarifications | ||||||||||||||
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. | |||||||||||||
| draft-ietf-core-dns-over-coap-09.txt | ||||||||||||||
| DNS over CoAP (DoC) | ||||||||||||||
|
This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). | |||||||||||||
| draft-ietf-core-groupcomm-bis-12.txt | ||||||||||||||
| Group Communication for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. | |||||||||||||
| draft-ietf-core-groupcomm-proxy-03.txt | ||||||||||||||
| Proxy Operations for CoAP Group Communication | ||||||||||||||
|
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. | |||||||||||||
| draft-ietf-core-href-16.txt | ||||||||||||||
| Constrained Resource Identifiers | ||||||||||||||
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the URI Schemes registry RFC 7595 describes cooperates with the CRI Scheme Numbers registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –16 of this draft continues -15 by picking up // more comments; it was made specifically for IETF 120. This // revision still contains open issues and is intended to serve as a // snapshot. | |||||||||||||
| draft-ietf-core-observe-multicast-notifications-10.txt | ||||||||||||||
| Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. | |||||||||||||
| draft-ietf-core-oscore-capable-proxies-03.txt | ||||||||||||||
| OSCORE-capable Proxies | ||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. | |||||||||||||
| draft-ietf-core-oscore-groupcomm-23.txt | ||||||||||||||
| Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. | |||||||||||||
| draft-ietf-core-oscore-id-update-01.txt | ||||||||||||||
| Identifier Update for OSCORE | ||||||||||||||
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. | |||||||||||||
| draft-ietf-core-oscore-key-limits-03.txt | ||||||||||||||
| Key Usage Limits for OSCORE | ||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. | |||||||||||||
| draft-ietf-core-oscore-key-update-09.txt | ||||||||||||||
| Key Update for OSCORE (KUDOS) | ||||||||||||||
|
This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. | |||||||||||||
| draft-ietf-core-transport-indication-07.txt | ||||||||||||||
| CoAP Transport Indication | ||||||||||||||
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. | |||||||||||||
| draft-ietf-cose-cbor-encoded-cert-11.txt | ||||||||||||||
| CBOR Encoded X.509 Certificates (C509 Certificates) | ||||||||||||||
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. | |||||||||||||
| draft-ietf-cose-dilithium-05.txt | ||||||||||||||
| ML-DSA for JOSE and COSE | ||||||||||||||
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. | |||||||||||||
| draft-ietf-cose-hash-envelope-01.txt | ||||||||||||||
| COSE Hash Envelope | ||||||||||||||
|
This document defines new COSE header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation as access to the original payload is not required for signature validation. Additionally, hints of the detached payload's content format and availability are defined providing references to optional discovery mechanisms that can help to find original payload content. | |||||||||||||
| draft-ietf-cose-hpke-09.txt | ||||||||||||||
| Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) | ||||||||||||||
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. | |||||||||||||
| draft-ietf-cose-merkle-tree-proofs-07.txt | ||||||||||||||
| COSE Receipts | ||||||||||||||
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. | |||||||||||||
| draft-ietf-cose-sphincs-plus-05.txt | ||||||||||||||
| SLH-DSA for JOSE and COSE | ||||||||||||||
|
This document describes JOSE and COSE serializations for SLH-DSA, which was derived from SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-205]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/ post-quantum-cryptography) standardization process. | |||||||||||||
| draft-ietf-cose-tsa-tst-header-parameter-03.txt | ||||||||||||||
| COSE Header parameter for RFC 3161 Time-Stamp Tokens | ||||||||||||||
|
This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message. 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/ietf-scitt/draft-birkholz-cose-tsa-tst-header- parameter. | |||||||||||||
| draft-ietf-dance-architecture-07.txt | ||||||||||||||
| An Architecture for DNS-Bound Client and Sender Identities | ||||||||||||||
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. | |||||||||||||
| draft-ietf-dance-client-auth-06.txt | ||||||||||||||
| TLS Client Authentication via DANE TLSA records | ||||||||||||||
|
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. | |||||||||||||
| draft-ietf-dance-tls-clientid-04.txt | ||||||||||||||
| TLS Extension for DANE Client Identity | ||||||||||||||
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. | |||||||||||||
| draft-ietf-deleg-requirements-02.txt | ||||||||||||||
| Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements | ||||||||||||||
|
Authoritative control of parts of the Domain Name System namespace are indicated with a special record type, the NS record, that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft considers the limitations of the current system, benefits that could be gained by changing it, and what requirements constrain an updated design. | |||||||||||||
| draft-ietf-detnet-controller-plane-framework-07.txt | ||||||||||||||
| Deterministic Networking (DetNet) Controller Plane Framework | ||||||||||||||
|
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. | |||||||||||||
| draft-ietf-detnet-dataplane-taxonomy-02.txt | ||||||||||||||
| Dataplane Enhancement Taxonomy | ||||||||||||||
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also briefly mentioned. Reference topologies for evaluation of the solutions are given as well. | |||||||||||||
| draft-ietf-detnet-raw-industrial-req-01.txt | ||||||||||||||
| Requirements for Reliable Wireless Industrial Services | ||||||||||||||
|
This document provides an overview of the communication requirements for handling reliable wireless services in the context of industrial environments. The aim of the draft is to raise awareness of the communication requirements of current and future wireless industrial services; how they can coexist with wired infrastructures; the key drivers for reliable wireless integration; the relevant communication requirements to be considered; the current and future challenges arising from the use of wireless services; and the potential benefits of wireless communication. | |||||||||||||
| draft-ietf-detnet-scaling-requirements-07.txt | ||||||||||||||
| Requirements for Scaling Deterministic Networks | ||||||||||||||
|
Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, a great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. | |||||||||||||
| draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-01.txt | ||||||||||||||
| DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support | ||||||||||||||
|
This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4- over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in contexts where it is not possible at the client. | |||||||||||||
| draft-ietf-dhc-rfc8415bis-07.txt | ||||||||||||||
| Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | ||||||||||||||
|
This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). | |||||||||||||
| draft-ietf-dmarc-aggregate-reporting-24.txt | ||||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) Aggregate Reporting | ||||||||||||||
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the Domain Owner's specified destination as supported by the receiver. | |||||||||||||
| draft-ietf-dmarc-dmarcbis-36.txt | ||||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) | ||||||||||||||
|
This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain (#author-domain) to enable validation of the domain's use, to indicate the Domain Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix- operator) message handling preference regarding failed validation, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. | |||||||||||||
| draft-ietf-dmarc-failure-reporting-11.txt | ||||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting | ||||||||||||||
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. | |||||||||||||
| draft-ietf-dmm-tn-aware-mobility-14.txt | ||||||||||||||
| Mobility-aware Transport Network Slicing for 5G | ||||||||||||||
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. | |||||||||||||
| draft-ietf-dnsop-avoid-fragmentation-20.txt | ||||||||||||||
| IP Fragmentation Avoidance in DNS over UDP | ||||||||||||||
|
The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. | |||||||||||||
| draft-ietf-dnsop-cds-consistency-05.txt | ||||||||||||||
| Clarifications on CDS/CDNSKEY and CSYNC Consistency | ||||||||||||||
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, RFC 7344 provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) can query these records from the child and, after validation, use them to update the parent-side RRsets of the delegation. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. | |||||||||||||
| draft-ietf-dnsop-compact-denial-of-existence-05.txt | ||||||||||||||
| Compact Denial of Existence in DNSSEC | ||||||||||||||
|
This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFC 4034 and 4035. | |||||||||||||
| draft-ietf-dnsop-dnssec-automation-03.txt | ||||||||||||||
| DNSSEC automation | ||||||||||||||
|
This document describes an algorithm and protocol to automate the setup, operations, and decomissioning of Multi-Signer DNSSEC [RFC8901] configurations. It employs Model 2 of the multi-signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), Managing DS Records from the Parent via CDS/ CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477] to accomplish this. | |||||||||||||
| draft-ietf-dnsop-domain-verification-techniques-06.txt | ||||||||||||||
| Domain Control Validation using DNS | ||||||||||||||
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. | |||||||||||||
| draft-ietf-dnsop-generalized-notify-04.txt | ||||||||||||||
| Generalized DNS Notifications | ||||||||||||||
|
This document extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC bootstrapping and key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new DSYNC record type. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-ietf-dnsop-grease-00.txt | ||||||||||||||
| Greasing Protocol Extension Points in the DNS | ||||||||||||||
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. | |||||||||||||
| draft-ietf-dnsop-must-not-ecc-gost-01.txt | ||||||||||||||
| Remove deprecated GOST algorithms from active use within DNSSEC | ||||||||||||||
|
This document retires the use of ECC-GOST within DNSSEC. | |||||||||||||
| draft-ietf-dnsop-must-not-sha1-01.txt | ||||||||||||||
| Remove SHA-1 from active use within DNSSEC | ||||||||||||||
|
This document retires the use of SHA-1 within DNSSEC. | |||||||||||||
| draft-ietf-dnsop-ns-revalidation-07.txt | ||||||||||||||
| Delegation Revalidation by DNS Resolvers | ||||||||||||||
|
This document recommends improved DNS [RFC1034] [RFC1035] resolver behavior with respect to the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the child delegation by re-querying the parent zone at the expiration of the TTL of the parent side NS RRset. | |||||||||||||
| draft-ietf-dnsop-rfc7958bis-06.txt | ||||||||||||||
| DNSSEC Trust Anchor Publication for the Root Zone | ||||||||||||||
|
The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. This document obsoletes RFC 7958. | |||||||||||||
| draft-ietf-dnsop-rfc8109bis-07.txt | ||||||||||||||
| Initializing a DNS Resolver with Priming Queries | ||||||||||||||
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. See Appendix A for the list of changes from RFC 8109. | |||||||||||||
| draft-ietf-dnsop-rfc8624-bis-02.txt | ||||||||||||||
| DNSSEC Cryptographic Algorithm Recommendation Update Process | ||||||||||||||
|
||||||||||||||
| draft-ietf-dnsop-structured-dns-error-10.txt | ||||||||||||||
| Structured Error Data for Filtered DNS | ||||||||||||||
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. | |||||||||||||
| draft-ietf-dnsop-svcb-dane-04.txt | ||||||||||||||
| Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC | ||||||||||||||
|
Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. | |||||||||||||
| draft-ietf-dnssd-multi-qtypes-06.txt | ||||||||||||||
| DNS Multiple QTYPEs | ||||||||||||||
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query (OpCode=0). | |||||||||||||
| draft-ietf-dnssd-srp-25.txt | ||||||||||||||
| Service Registration Protocol for DNS-Based Service Discovery | ||||||||||||||
|
The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. | |||||||||||||
| draft-ietf-dnssd-update-lease-08.txt | ||||||||||||||
| An EDNS(0) option to negotiate Leases on DNS Updates | ||||||||||||||
|
This document describes an EDNS(0) option that can be used by DNS Update requestors and DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale resource records that have been added by DNS Updates | |||||||||||||
| draft-ietf-drip-dki-03.txt | ||||||||||||||
| The DRIP DET public Key Infrastructure | ||||||||||||||
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. | |||||||||||||
| draft-ietf-drip-registries-21.txt | ||||||||||||||
| DRIP Entity Tags (DET) in the Domain Name System (DNS) | ||||||||||||||
|
This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata. | |||||||||||||
| draft-ietf-dtn-adm-yang-01.txt | ||||||||||||||
| DTNMA Application Data Model (ADM) YANG Syntax | ||||||||||||||
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data-value syntax. | |||||||||||||
| draft-ietf-dtn-amm-01.txt | ||||||||||||||
| DTNMA Application Management Model (AMM) and Data Models | ||||||||||||||
|
This document defines a data model that captures the information necessary to asynchronously manage applications within the Delay- Tolerant Networking Management Architecture (DTNMA). This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements. | |||||||||||||
| draft-ietf-dtn-amp-00.txt | ||||||||||||||
| DTNMA Asynchronous Management Protocol (AMP) | ||||||||||||||
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport mapping for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management of resource constrained devices and over challenged networks. | |||||||||||||
| draft-ietf-dtn-ari-02.txt | ||||||||||||||
| DTNMA Application Resource Identifier (ARI) | ||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. | |||||||||||||
| draft-ietf-dtn-bibect-04.txt | ||||||||||||||
| Bundle-in-Bundle Encapsulation | ||||||||||||||
|
This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called "custody transfer". This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. | |||||||||||||
| draft-ietf-dtn-bpsec-cose-05.txt | ||||||||||||||
| DTN Bundle Protocol Security (BPSec) COSE Context | ||||||||||||||
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. | |||||||||||||
| draft-ietf-dtn-bpv7-admin-iana-04.txt | ||||||||||||||
| Bundle Protocol Version 7 Administrative Record Types Registry | ||||||||||||||
|
This document updates RFC 9171 to clarify that a Bundle Protocol Version 7 agent is intended to use an IANA registry for Administrative Record types. It also makes a code point reservations for private and experimental use. | |||||||||||||
| draft-ietf-dtn-eid-pattern-00.txt | ||||||||||||||
| Bundle Protocol Endpoint ID Patterns | ||||||||||||||
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. | |||||||||||||
| draft-ietf-dtn-ipn-update-14.txt | ||||||||||||||
| Update to the ipn URI scheme | ||||||||||||||
|
This document updates the specification of the ipn URI scheme previously defined in RFC 6260, the IANA registries established in RFC 7116, and the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in Bundle Protocol Version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the ipn URI scheme, define new encodings of ipn scheme URIs, and establish the registries necessary to manage this scheme. | |||||||||||||
| draft-ietf-dtn-udpcl-00.txt | ||||||||||||||
| Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 | ||||||||||||||
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of RFC7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unreliable transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. | |||||||||||||
| draft-ietf-dult-accessory-protocol-00.txt | ||||||||||||||
| Detecting Unwanted Location Trackers Accessory Protocol | ||||||||||||||
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. | |||||||||||||
| draft-ietf-dult-finding-00.txt | ||||||||||||||
| Finding Tracking Tags | ||||||||||||||
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. This document defines the protocol by which devices report tags they have seen and by which owners look up their location. | |||||||||||||
| draft-ietf-dult-threat-model-00.txt | ||||||||||||||
| DULT Threat Model | ||||||||||||||
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted location trackers must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, will define what is in and out of scope for the unwanted location tracking protocols, and will provide some design considerations for implementation of protocols to detect unwanted location tracking. | |||||||||||||
| draft-ietf-ecrit-lost-planned-changes-11.txt | ||||||||||||||
| Validation of Locations Around a Planned Change | ||||||||||||||
|
This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to location data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, since at a known future date, previously valid records may become invalid, and new records may become valid. This extension adds an element to the | |||||||||||||
| draft-ietf-ecrit-similar-location-19.txt | ||||||||||||||
| A LoST extension to return complete and similar location info | ||||||||||||||
|
This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a | |||||||||||||
| draft-ietf-emailcore-as-13.txt | ||||||||||||||
| Applicability Statement for IETF Core Email Protocols | ||||||||||||||
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. Open Issues * #92 - CNAME handling in "5.1. Locating the Target Host" (https://github.com/ietf-wg-emailcore/emailcore/issues/92): Per IETF 120, Klensin to propose text. * #93 - "7.3. VRFY, EXPN, and Security" should point to SMTP AUTH RFC (https://github.com/ietf-wg-emailcore/emailcore/issues/93): Per IETF 120, Alexey to propose text or close issue. | |||||||||||||
| draft-ietf-emailcore-rfc5321bis-37.txt | ||||||||||||||
| Simple Mail Transfer Protocol | ||||||||||||||
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. | |||||||||||||
| draft-ietf-emailcore-rfc5322bis-12.txt | ||||||||||||||
| Internet Message Format | ||||||||||||||
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. | |||||||||||||
| draft-ietf-emu-aka-pfs-12.txt | ||||||||||||||
| Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) | ||||||||||||||
|
This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead. | |||||||||||||
| draft-ietf-emu-bootstrapped-tls-07.txt | ||||||||||||||
| Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) | ||||||||||||||
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. | |||||||||||||
| draft-ietf-emu-eap-arpa-03.txt | ||||||||||||||
| The eap.arpa domain and EAP provisioning | ||||||||||||||
|
This document defines the eap.arpa domain as a way for EAP peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain pre-defined identifiers which use the Network Access Identifier (NAI) format of RFC7542. A table of identifiers and meanings is defined. | |||||||||||||
| draft-ietf-emu-eap-edhoc-02.txt | ||||||||||||||
| Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | ||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE to provide security services efficiently encoded in CBOR. This document also provides guidance on authentication and authorization for EAP-EDHOC. | |||||||||||||
| draft-ietf-emu-eap-fido-00.txt | ||||||||||||||
| EAP-FIDO | ||||||||||||||
|
This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. 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-ietf-emu-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/. | |||||||||||||
| draft-ietf-emu-rfc7170bis-19.txt | ||||||||||||||
| Tunnel Extensible Authentication Protocol (TEAP) Version 1 | ||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. | |||||||||||||
| draft-ietf-extra-6855bis-04.txt | ||||||||||||||
| IMAP Support for UTF-8 | ||||||||||||||
|
This specification extends the Internet Message Access Protocol (IMAP4rev1, RFC 3501) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 [RFC9051], since that protocol includes everything in this extension. | |||||||||||||
| draft-ietf-extra-imap-messagelimit-10.txt | ||||||||||||||
| IMAP MESSAGELIMIT Extension | ||||||||||||||
|
The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE (or their UID variants), APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by corresponding IMAP server and avoid issuing commands that would exceed such limit. | |||||||||||||
| draft-ietf-extra-jmapaccess-09.txt | ||||||||||||||
| The JMAPACCESS Extension for IMAP | ||||||||||||||
|
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via JMAP, and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. | |||||||||||||
| draft-ietf-gnap-resource-servers-09.txt | ||||||||||||||
| Grant Negotiation and Authorization Protocol Resource Server Connections | ||||||||||||||
|
GNAP defines a mechanism for delegating authorization to a piece of software (the client), and conveying the results and artifacts of that delegation to the software. This extension defines methods for resource servers (RS) to connect with authorization servers (AS) in an interoperable fashion. | |||||||||||||
| draft-ietf-grow-as-path-prepending-13.txt | ||||||||||||||
| AS Path Prepending | ||||||||||||||
|
AS Path Prepending provides a tool to manipulate the BGP AS_PATH attribute through prepending multiple entries of an ASN. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the Internet. This document provides guidance for the use of AS Path Prepending, including alternative solutions, in order to avoid negatively affecting the Internet. | |||||||||||||
| draft-ietf-grow-bgpopsecupd-04.txt | ||||||||||||||
| Updated BGP Operations and Security | ||||||||||||||
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability requirements that can and should be ensured to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454 / BCP194, several developments and changes in operational practice took place that warrant an update of these best current practices. This document replaces RFC7454 / BCP194, focusing on the overall goals, and providing a less implementation centric set of best practices. To this end, the document describes the security requirements and goals when operating BGP for exchanging routing information with other networks. The document explicitly does not focus on specific technical implementations and requirements. Operators are advised to consult documentation and contemporary informational documents concerning methods to ensure that these properties are sufficiently ensured in their network. | |||||||||||||
| draft-ietf-grow-bmp-bgp-rib-stats-05.txt | ||||||||||||||
| Definition For New BMP Statistics Type | ||||||||||||||
|
RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router. This document updates RFC 7854 by adding new statistics type to monitor BMP rib-in and rib- out Ribs. | |||||||||||||
| draft-ietf-grow-bmp-path-marking-tlv-02.txt | ||||||||||||||
| BMP Extension for Path Status TLV | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a path after being processed by the BGP process. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-ietf-grow-bmp-tlv-ebit [I-D.ietf-grow-bmp-tlv-ebit]. | |||||||||||||
| draft-ietf-grow-bmp-peer-up-05.txt | ||||||||||||||
| BMP Peer Up Message Namespace | ||||||||||||||
|
RFC 7854, BGP Monitoring Protocol, uses different message types for different purposes. Most of these are Type, Length, Value (TLV) structured. One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Subsequent experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol. This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFC 8671 and RFC 9069 by moving the defined codepoints in the newly introduced registry. Compliant implementations of RFC 7854, RFC 8671 and RFC 9069 also comply with this specification. | |||||||||||||
| draft-ietf-grow-bmp-rel-02.txt | ||||||||||||||
| Logging of routing events in BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis. | |||||||||||||
| draft-ietf-grow-bmp-tcp-ao-00.txt | ||||||||||||||
| TCP-AO Protection for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. 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/hmntsharma/draft-hmntsharma-bmp-tcp-ao. | |||||||||||||
| draft-ietf-grow-bmp-yang-04.txt | ||||||||||||||
| BMP YANG Module | ||||||||||||||
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). | |||||||||||||
| draft-ietf-grow-ixp-ext-comms-01.txt | ||||||||||||||
| Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers | ||||||||||||||
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. | |||||||||||||
| draft-ietf-grow-nrtm-v4-05.txt | ||||||||||||||
| Near Real Time Mirroring (NRTM) version 4 | ||||||||||||||
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. | |||||||||||||
| draft-ietf-grow-peering-api-00.txt | ||||||||||||||
| Peering API | ||||||||||||||
|
We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. | |||||||||||||
| draft-ietf-grow-route-leak-detection-mitigation-11.txt | ||||||||||||||
| Methods for Detection and Mitigation of BGP Route Leaks | ||||||||||||||
|
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. | |||||||||||||
| draft-ietf-grow-yang-bgp-communities-02.txt | ||||||||||||||
| YANG Module for BGP Communities | ||||||||||||||
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardised format. | |||||||||||||
| draft-ietf-httpapi-api-catalog-08.txt | ||||||||||||||
| api-catalog: a well-known URI and link relation to help discovery of APIs | ||||||||||||||
|
This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published APIs. A request to the api-catalog resource will return a document providing information about, and links to, the publisher's APIs. | |||||||||||||
| draft-ietf-httpapi-deprecation-header-09.txt | ||||||||||||||
| The Deprecation HTTP Header Field | ||||||||||||||
|
The Deprecation HTTP response header field is used to signal to consumers of a resource (in the sense of URI) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional information about planned or existing deprecation, and possibly ways in which client application developers can best manage deprecation. | |||||||||||||
| draft-ietf-httpapi-digest-fields-problem-types-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-httpapi-patch-byterange-02.txt | ||||||||||||||
| Byte Range PATCH | ||||||||||||||
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, facilitating random access writes and segmented uploads of resources. | |||||||||||||
| draft-ietf-httpapi-privacy-00.txt | ||||||||||||||
| API Keys and Privacy | ||||||||||||||
|
Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. | |||||||||||||
| draft-ietf-httpapi-ratelimit-headers-08.txt | ||||||||||||||
| RateLimit header fields for HTTP | ||||||||||||||
|
This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. | |||||||||||||
| draft-ietf-httpapi-rest-api-mediatypes-06.txt | ||||||||||||||
| REST API Media Types | ||||||||||||||
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. | |||||||||||||
| draft-ietf-httpbis-compression-dictionary-19.txt | ||||||||||||||
| Compression Dictionary Transport | ||||||||||||||
|
This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol. | |||||||||||||
| draft-ietf-httpbis-connect-tcp-06.txt | ||||||||||||||
| Template-Driven HTTP CONNECT Proxying for TCP | ||||||||||||||
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. | |||||||||||||
| draft-ietf-httpbis-no-vary-search-00.txt | ||||||||||||||
| No-Vary-Search | ||||||||||||||
|
A proposed HTTP header field for changing how URL search parameters impact caching. | |||||||||||||
| draft-ietf-httpbis-optimistic-upgrade-01.txt | ||||||||||||||
| Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 | ||||||||||||||
|
In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues. | |||||||||||||
| draft-ietf-httpbis-resumable-upload-05.txt | ||||||||||||||
| Resumable Uploads for HTTP | ||||||||||||||
|
HTTP clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. Prior to interruption, part of a representation may have been exchanged. To complete the data transfer of the entire representation, it is often desirable to issue subsequent requests that transfer only the remainder of the representation. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. | |||||||||||||
| draft-ietf-httpbis-rfc6265bis-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-httpbis-safe-method-w-body-07.txt | ||||||||||||||
| The HTTP QUERY Method | ||||||||||||||
|
This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. | |||||||||||||
| draft-ietf-httpbis-secondary-server-certs-01.txt | ||||||||||||||
| Secondary Certificate Authentication of HTTP Servers | ||||||||||||||
|
This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. | |||||||||||||
| draft-ietf-httpbis-unprompted-auth-12.txt | ||||||||||||||
| The Concealed HTTP Authentication Scheme | ||||||||||||||
|
Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme. | |||||||||||||
| draft-ietf-i2nsf-applicability-18.txt | ||||||||||||||
| Applicability of Interfaces to Network Security Functions to Network-Based Security Services | ||||||||||||||
|
This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. | |||||||||||||
| draft-ietf-i2nsf-capability-data-model-32.txt | ||||||||||||||
| I2NSF Capability YANG Data Model | ||||||||||||||
|
This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. | |||||||||||||
| draft-ietf-i2nsf-consumer-facing-interface-dm-31.txt | ||||||||||||||
| I2NSF Consumer-Facing Interface YANG Data Model | ||||||||||||||
|
This document describes a YANG data model of the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. This document defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. The YANG data model is based on the "Event-Condition-Action" (ECA) policy defined by a capability YANG data model for I2NSF. The YANG data model enables different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain (e.g., user group). | |||||||||||||
| draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt | ||||||||||||||
| I2NSF Network Security Function-Facing Interface YANG Data Model | ||||||||||||||
|
This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework. | |||||||||||||
| draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt | ||||||||||||||
| I2NSF NSF Monitoring Interface YANG Data Model | ||||||||||||||
|
This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model. | |||||||||||||
| draft-ietf-i2nsf-registration-interface-dm-26.txt | ||||||||||||||
| I2NSF Registration Interface YANG Data Model for NSF Capability Registration | ||||||||||||||
|
This document defines a YANG data model for the Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of this data model is to support NSF capability registration and query via I2NSF Registration Interface. | |||||||||||||
| draft-ietf-idr-5g-edge-service-metadata-25.txt | ||||||||||||||
| BGP Extension for 5G Edge Service Metadata | ||||||||||||||
|
This draft describes a new Metadata Path Attribute and some Sub-TLVs for egress routers to advertise the Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE). | |||||||||||||
| draft-ietf-idr-bgp-bfd-strict-mode-13.txt | ||||||||||||||
| BGP BFD Strict-Mode | ||||||||||||||
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode". | |||||||||||||
| draft-ietf-idr-bgp-car-10.txt | ||||||||||||||
| BGP Color-Aware Routing (CAR) | ||||||||||||||
|
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. | |||||||||||||
| draft-ietf-idr-bgp-ct-33.txt | ||||||||||||||
| BGP Classful Transport Planes | ||||||||||||||
|
This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 procedures and follows RFC 8277 NLRI encoding is defined to advertise underlay routes with its identified class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. | |||||||||||||
| draft-ietf-idr-bgp-ct-srv6-06.txt | ||||||||||||||
| BGP CT - Adaptation to SRv6 dataplane | ||||||||||||||
|
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document. | |||||||||||||
| draft-ietf-idr-bgp-fwd-rr-03.txt | ||||||||||||||
| BGP Route Reflector with Next Hop Self | ||||||||||||||
|
The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains. | |||||||||||||
| draft-ietf-idr-bgp-generic-metric-00.txt | ||||||||||||||
| Accumulated Metric in NHC attribute | ||||||||||||||
|
RFC7311 describes mechanism for carrying accumulated IGP cost across BGP domains however it limits to IGP-metric only. There is a need to accumulate and propagate different types of metrics as it will aid in intent-based end-to-end path across BGP domains. This document defines BGP extensions for Generic Metric sub-types that enable different types of metrics to be accumulated and carried in BGP. This is applicable when multiple domains exchange BGP routing information. | |||||||||||||
| draft-ietf-idr-bgp-ifit-capabilities-06.txt | ||||||||||||||
| Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. | |||||||||||||
| draft-ietf-idr-bgp-ls-link-mtu-08.txt | ||||||||||||||
| Signaling Maximum Transmission Unit (MTU) using BGP-LS | ||||||||||||||
|
BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-10.txt | ||||||||||||||
| Advertisement of Segment Routing Policies using BGP Link-State | ||||||||||||||
|
This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-nrp-00.txt | ||||||||||||||
| SR Policies Extensions for Network Resource Partition in BGP-LS | ||||||||||||||
|
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 ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-path-segment-08.txt | ||||||||||||||
| SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS | ||||||||||||||
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. | |||||||||||||
| draft-ietf-idr-bgp-ls-te-path-02.txt | ||||||||||||||
| Advertisement of Traffic Engineering Paths using BGP Link-State | ||||||||||||||
|
This document describes a mechanism to collect the Traffic Engineering Path information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re- optimization, service placement, network visualization, etc. | |||||||||||||
| draft-ietf-idr-bgp-model-18.txt | ||||||||||||||
| YANG Model for Border Gateway Protocol (BGP-4) | ||||||||||||||
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. | |||||||||||||
| draft-ietf-idr-bgp-sr-segtypes-ext-06.txt | ||||||||||||||
| Segment Routing Segment Types Extensions for BGP SR Policy | ||||||||||||||
|
This document specifies the signaling of additional Segment Routing Segment Types for signaling of Segment Routing (SR) Policies in BGP using SR Policy Subsequent Address Family Identifier. | |||||||||||||
| draft-ietf-idr-bgp-srmpls-elp-02.txt | ||||||||||||||
| BGP Extension for SR-MPLS Entropy Label Position | ||||||||||||||
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. | |||||||||||||
| draft-ietf-idr-bgpls-sr-vtn-mt-07.txt | ||||||||||||||
| Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRP) | ||||||||||||||
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics to customers who have specific requirements on their connectivity, such as guaranteed resources, latency, or jitter. Enhanced VPNs require 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. When Segment Routing is used as the data plane of NRPs, each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to distribute the information of SR based NRPs using BGP-Link State (BGP-LS) with Multi-Topology (MT). | |||||||||||||
| draft-ietf-idr-cpr-04.txt | ||||||||||||||
| BGP Colored Prefix Routing (CPR) for SRv6 based Services | ||||||||||||||
|
This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored prefixes. This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. The existing IPv6 Address Family and Color Extended Community are reused for the advertisement of IPv6 Colored prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks. | |||||||||||||
| draft-ietf-idr-deprecate-as-set-confed-set-16.txt | ||||||||||||||
| Deprecation of AS_SET and AS_CONFED_SET in BGP | ||||||||||||||
|
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472. | |||||||||||||
| draft-ietf-idr-entropy-label-16.txt | ||||||||||||||
| BGP Next Hop Dependent Characteristics Attribute | ||||||||||||||
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. This specification also defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. | |||||||||||||
| draft-ietf-idr-flowspec-l2vpn-24.txt | ||||||||||||||
| BGP Dissemination of L2 Flow Specification Rules | ||||||||||||||
|
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. | |||||||||||||
| draft-ietf-idr-flowspec-network-slice-ts-03.txt | ||||||||||||||
| BGP Flowspec for IETF Network Slice Traffic Steering | ||||||||||||||
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic flow specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be preformed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). | |||||||||||||
| draft-ietf-idr-flowspec-nvo3-21.txt | ||||||||||||||
| BGP Dissemination of Flow Specification Rules for Tunneled Traffic | ||||||||||||||
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. | |||||||||||||
| draft-ietf-idr-flowspec-redirect-ip-03.txt | ||||||||||||||
| BGP Flow-Spec Redirect-to-IP Action | ||||||||||||||
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard [RFC5575] defines a redirect-to-VRF action for policy-based forwarding. This mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities. | |||||||||||||
| draft-ietf-idr-flowspec-srv6-06.txt | ||||||||||||||
| BGP Flow Specification for SRv6 | ||||||||||||||
|
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. | |||||||||||||
| draft-ietf-idr-fsv2-ip-basic-02.txt | ||||||||||||||
| BGP Flow Specification Version 2 - for Basic IP | ||||||||||||||
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. | |||||||||||||
| draft-ietf-idr-legacy-rtc-11.txt | ||||||||||||||
| Automatic Route Target Filtering for legacy PEs | ||||||||||||||
|
This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. | |||||||||||||
| draft-ietf-idr-link-bandwidth-09.txt | ||||||||||||||
| BGP Link Bandwidth Extended Community | ||||||||||||||
|
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. | |||||||||||||
| draft-ietf-idr-mpbgp-extension-4map6-03.txt | ||||||||||||||
| MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement | ||||||||||||||
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. | |||||||||||||
| draft-ietf-idr-multinexthop-attribute-03.txt | ||||||||||||||
| BGP MultiNexthop Attribute | ||||||||||||||
|
Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update message. This nexthop can be encoded in either the top- level BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). Forwarding information related to the nexthop is scattered across various attributes, extended communities or the NLRI field. This document defines a new optional non-transitive BGP attribute called "MultiNexthop (MNH)" with IANA code TBD. The MNH provides two things: it allows carrying the Nexthop and related forwarding information in one BGP attribute. The MNH also enables carrying an ordered set of multiple Nexthops in the same attribute, with forwarding information scoped on a per Nexthop basis. | |||||||||||||
| draft-ietf-idr-performance-routing-04.txt | ||||||||||||||
| Performance-based BGP Routing Mechanism | ||||||||||||||
|
The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. | |||||||||||||
| draft-ietf-idr-rt-derived-community-04.txt | ||||||||||||||
| Extended Communities Derived from Route Targets | ||||||||||||||
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. | |||||||||||||
| draft-ietf-idr-sdwan-edge-discovery-18.txt | ||||||||||||||
| BGP UPDATE for SD-WAN Edge Discovery | ||||||||||||||
|
The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. | |||||||||||||
| draft-ietf-idr-sr-epe-over-l2bundle-00.txt | ||||||||||||||
| Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members | ||||||||||||||
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. | |||||||||||||
| draft-ietf-idr-sr-policy-ifit-09.txt | ||||||||||||||
| BGP SR Policy Extensions to Enable IFIT | ||||||||||||||
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. | |||||||||||||
| draft-ietf-idr-sr-policy-nrp-01.txt | ||||||||||||||
| BGP SR Policy Extensions for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. | |||||||||||||
| draft-ietf-idr-sr-policy-path-mtu-10.txt | ||||||||||||||
| Segment Routing Path MTU in BGP | ||||||||||||||
|
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 SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. | |||||||||||||
| draft-ietf-idr-sr-policy-path-segment-13.txt | ||||||||||||||
| SR Policy Extensions for Path Segment and Bidirectional Path | ||||||||||||||
|
A Segment Routing(SR) policy identifies a set of candidate SR paths Each SR path is passed in BGP as the SR Policy SAFI NLRI accompanied with the Tunnel Encapsulation attribute (Tunnel-encaps). Each SR Path (tunnel) uses a set of TLVs in the Tunnel-encaps attribute to describe the characteristics of the SR Policy tunnel. One of the TLVs that describes the tunnel is the Segment list TLV which provides a list of segments contained in the tunnel. This document specifies a new Path Segment Sub-TLV to associate a Path Segment ID to the SR Segment List. The Path Segment ID can be used for performance measurement, path correlation, and end-2-end path protection. This Path Segment identifier can be also be used to correlate two unidirectional SR paths into a bidirectional SR path. Bidirection SR path may be required in some scenarios such as mobile backhaul transport network. | |||||||||||||
| draft-ietf-idr-sr-policy-safi-10.txt | ||||||||||||||
| Advertising Segment Routing Policies in BGP | ||||||||||||||
|
A Segment Routing (SR) Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI to advertise a candidate path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. | |||||||||||||
| draft-ietf-idr-sr-policy-seglist-id-02.txt | ||||||||||||||
| BGP SR Policy Extensions for Segment List Identifier | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. | |||||||||||||
| draft-ietf-idr-sr-te-policy-attr-01.txt | ||||||||||||||
| Advertising SID Algorithm Information in BGP | ||||||||||||||
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. | |||||||||||||
| draft-ietf-idr-ts-flowspec-srv6-policy-04.txt | ||||||||||||||
| Traffic Steering using BGP FlowSpec with SR Policy | ||||||||||||||
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. | |||||||||||||
| draft-ietf-idr-vpn-prefix-orf-08.txt | ||||||||||||||
| VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 | ||||||||||||||
|
This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. | |||||||||||||
| draft-ietf-intarea-extended-icmp-nodeid-00.txt | ||||||||||||||
| Extending ICMP for Node Identification | ||||||||||||||
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). | |||||||||||||
| draft-ietf-intarea-proxy-config-02.txt | ||||||||||||||
| Communicating Proxy Configurations in Provisioning Domains | ||||||||||||||
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and a list of DNS zones that are accessible via a proxy. 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/tfpauly/privacy-proxy. | |||||||||||||
| draft-ietf-intarea-tunnels-14.txt | ||||||||||||||
| IP Tunnels in the Internet Architecture | ||||||||||||||
|
This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels. | |||||||||||||
| draft-ietf-iotops-7228bis-00.txt | ||||||||||||||
| Terminology for Constrained-Node Networks | ||||||||||||||
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. | |||||||||||||
| draft-ietf-iotops-security-protocol-comparison-07.txt | ||||||||||||||
| Comparison of CoAP Security Protocols | ||||||||||||||
|
This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. | |||||||||||||
| draft-ietf-iotops-security-summary-03.txt | ||||||||||||||
| A summary of security-enabling technologies for IoT devices | ||||||||||||||
|
The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies. | |||||||||||||
| draft-ietf-ippm-alt-mark-deployment-02.txt | ||||||||||||||
| Alternate Marking Deployment Framework | ||||||||||||||
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. | |||||||||||||
| draft-ietf-ippm-asymmetrical-pkts-02.txt | ||||||||||||||
| Performance Measurement with Asymmetrical Packets in STAMP | ||||||||||||||
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. | |||||||||||||
| draft-ietf-ippm-capacity-protocol-10.txt | ||||||||||||||
| Test Protocol for One-way IP Capacity Measurement | ||||||||||||||
|
This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements. | |||||||||||||
| draft-ietf-ippm-connectivity-monitoring-09.txt | ||||||||||||||
| A Connectivity Monitoring Metric for IPPM | ||||||||||||||
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. | |||||||||||||
| draft-ietf-ippm-encrypted-pdmv2-09.txt | ||||||||||||||
| IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option | ||||||||||||||
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. | |||||||||||||
| draft-ietf-ippm-hybrid-two-step-03.txt | ||||||||||||||
| Hybrid Two-Step Performance Measurement Method | ||||||||||||||
|
The development and advancements in network operation automation have brought new measurement methodology requirements. mong them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. That task can be solved using on-path telemetry, also called hybrid measurement. An on-path telemetry method allows the collection of essential information that reflects the operational state and network performance experienced by the packet. This document introduces a method complementary to on-path telemetry that causes the generation of telemetry information. This method, referred to as Hybrid Two-Step (HTS), separates the act of measuring and/or calculating the performance metric from collecting and transporting network state. The HTS packet traverses the same set of nodes and links as the trigger packet, thus simplifying the correlation of informational elements originating on nodes traversed by the trigger packet. | |||||||||||||
| draft-ietf-ippm-ioam-data-integrity-12.txt | ||||||||||||||
| Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields. | |||||||||||||
| draft-ietf-ippm-qoo-01.txt | ||||||||||||||
| Quality of Outcome | ||||||||||||||
|
This document describes a new network quality framework named Quality of Outcome (QoO). The QoO framework is unique among network quality frameworks because it is designed to meet the needs of application developers, users and operators. This is achieved by basing the framework on Quality Attenuation, defining a simple format for specifying application requirements, and defining a way to compute a simple and intuitive user-facing metric. The framework proposes a way of sampling network quality, setting network quality requirements and a formula for calculating the probability for the sampled network to satisfy network requirements. | |||||||||||||
| draft-ietf-ippm-responsiveness-05.txt | ||||||||||||||
| Responsiveness under Working Conditions | ||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of latency, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. | |||||||||||||
| draft-ietf-ippm-stamp-ext-hdr-01.txt | ||||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers, IPv6 extension headers, and MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. | |||||||||||||
| draft-ietf-ipsecme-diet-esp-03.txt | ||||||||||||||
| ESP Header Compression Profile | ||||||||||||||
|
The document specifies Diet-ESP, an ESP Header Compression Profile (EHCP) that compresses IPsec/ESP communications using Static Context Header Compression (SCHC). | |||||||||||||
| draft-ietf-ipsecme-g-ikev2-18.txt | ||||||||||||||
| Group Key Management using IKEv2 | ||||||||||||||
|
This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. | |||||||||||||
| draft-ietf-ipsecme-ikev2-diet-esp-extension-02.txt | ||||||||||||||
| Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) | ||||||||||||||
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rules Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. | |||||||||||||
| draft-ietf-ipsecme-ikev2-qr-alt-05.txt | ||||||||||||||
| Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security | ||||||||||||||
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekey operations. This draft updates RFC8784 by extending use of PPKs. | |||||||||||||
| draft-ietf-ipsecme-ikev2-rename-esn-01.txt | ||||||||||||||
| Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This documents clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers Properties (SNP)". It also renames two currently defined values for this transform type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". | |||||||||||||
| draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-03.txt | ||||||||||||||
| IKEv2 Optional SA&TS Payloads in Child Exchange | ||||||||||||||
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. | |||||||||||||
| draft-ietf-isis-sr-yang-23.txt | ||||||||||||||
| A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane | ||||||||||||||
|
This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. | |||||||||||||
| draft-ietf-ivy-network-inventory-location-00.txt | ||||||||||||||
| A YANG Data Model for Network Inventory Location | ||||||||||||||
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. | |||||||||||||
| draft-ietf-ivy-network-inventory-software-00.txt | ||||||||||||||
| A YANG Network Data Model of Network Inventory Software Extensions | ||||||||||||||
|
The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for non-physical NEs (e.g., controllers, virtual routers, virtual firewalls) and software components (e.g., platform operating system (OS), software-patch). | |||||||||||||
| draft-ietf-ivy-network-inventory-topology-00.txt | ||||||||||||||
| A Network Inventory Topology Model | ||||||||||||||
|
This document defines a YANG model for network inventory topology to correlate the network inventory data with the general topology model to form a base underlay network, which can facilitate the mapping and correlation of the layer (e.g. Layer 2, Layer3) topology information above to the inventory data of the underlay network for agile service provisioning and network maintenance analysis. | |||||||||||||
| draft-ietf-ivy-network-inventory-yang-04.txt | ||||||||||||||
| A Base YANG Data Model for Network Inventory | ||||||||||||||
|
This document defines a base YANG data model for network inventory. The scope of this base model is set to be application- and technology-agnostic. However, the data model is designed with appropriate provisions to ease future augmentations with application- specific and technology-specific details. | |||||||||||||
| draft-ietf-jmap-calendars-22.txt | ||||||||||||||
| JSON Meta Application Protocol (JMAP) for Calendars | ||||||||||||||
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. | |||||||||||||
| draft-ietf-jmap-essential-01.txt | ||||||||||||||
| JMAP Essential Profile | ||||||||||||||
|
JMAP (RFC8620) is a generic, efficient, mobile friendly and scalable protocol that can be used for data of any type. This makes it a good fit for migrations or data portability use cases that are focusing on data import and export. However, due to its large set of features, it is also quite complex, which makes it difficult to explore new application domains in practice. The goal of this document is to provide guidelines on implementing essential parts of JMAP for a much lower entry barrier and more efficient implementation of the protocol. | |||||||||||||
| draft-ietf-jmap-filenode-00.txt | ||||||||||||||
| JMAP File Storage extension | ||||||||||||||
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. | |||||||||||||
| draft-ietf-jmap-webpush-vapid-05.txt | ||||||||||||||
| Use of VAPID in JMAP WebPush | ||||||||||||||
|
This document defines a method for JMAP servers to advertise their capability to authenticate WebPush notifications using the Voluntary Application Server Identification protocol. | |||||||||||||
| draft-ietf-jose-deprecate-none-rsa15-00.txt | ||||||||||||||
| JOSE: Deprecate 'none' and 'RSA1_5' | ||||||||||||||
|
This draft updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. | |||||||||||||
| draft-ietf-jose-fully-specified-algorithms-06.txt | ||||||||||||||
| Fully-Specified Algorithms for JOSE and COSE | ||||||||||||||
|
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. | |||||||||||||
| draft-ietf-jose-hpke-encrypt-04.txt | ||||||||||||||
| Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) | ||||||||||||||
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with JOSE. | |||||||||||||
| draft-ietf-jose-json-proof-algorithms-07.txt | ||||||||||||||
| JSON Proof Algorithms | ||||||||||||||
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. | |||||||||||||
| draft-ietf-jose-json-proof-token-07.txt | ||||||||||||||
| JSON Proof Token | ||||||||||||||
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). | |||||||||||||
| draft-ietf-jose-json-web-proof-07.txt | ||||||||||||||
| JSON Web Proof | ||||||||||||||
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay. | |||||||||||||
| draft-ietf-jose-pqc-kem-00.txt | ||||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE | ||||||||||||||
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. 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-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. | |||||||||||||
| draft-ietf-keytrans-architecture-02.txt | ||||||||||||||
| Key Transparency Architecture | ||||||||||||||
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply KT to a number of common applications. | |||||||||||||
| draft-ietf-keytrans-protocol-00.txt | ||||||||||||||
| Key Transparency Protocol | ||||||||||||||
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. | |||||||||||||
| draft-ietf-kitten-scram-2fa-05.txt | ||||||||||||||
| Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication | ||||||||||||||
|
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey). | |||||||||||||
| draft-ietf-lake-app-profiles-00.txt | ||||||||||||||
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. This document defines a number of means to coordinate the use and discovery of EDHOC application profiles. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, this document defines a set of well-known EDHOC application profiles. | |||||||||||||
| draft-ietf-lake-authz-03.txt | ||||||||||||||
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | ||||||||||||||
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. | |||||||||||||
| draft-ietf-lake-edhoc-impl-cons-02.txt | ||||||||||||||
| Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). | |||||||||||||
| draft-ietf-lamps-attestation-freshness-03.txt | ||||||||||||||
| Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) | ||||||||||||||
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) | |||||||||||||
| draft-ietf-lamps-automation-keyusages-01.txt | ||||||||||||||
| X.509 Certificate Extended Key Usage (EKU) for Automation | ||||||||||||||
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines KeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety- critical communication to be included in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by industrial automation and the ERJU System Pillar. | |||||||||||||
| draft-ietf-lamps-cert-binding-for-multi-auth-06.txt | ||||||||||||||
| Related Certificates for Use in Multiple Authentications within a Protocol | ||||||||||||||
|
This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. | |||||||||||||
| draft-ietf-lamps-cms-cek-hkdf-sha256-05.txt | ||||||||||||||
| Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256 | ||||||||||||||
|
This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated- encryption algorithm identifier. | |||||||||||||
| draft-ietf-lamps-cms-kyber-07.txt | ||||||||||||||
| Use of ML-KEM in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameters sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML- KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. | |||||||||||||
| draft-ietf-lamps-cms-ml-dsa-01.txt | ||||||||||||||
| Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. | |||||||||||||
| draft-ietf-lamps-cms-sphincs-plus-17.txt | ||||||||||||||
| Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. | |||||||||||||
| draft-ietf-lamps-csr-attestation-14.txt | ||||||||||||||
| Use of Remote Attestation with Certification Signing Requests | ||||||||||||||
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence in Certificate Signing Requests (CSRs) such as PKCS#10 or Certificate Request Message Format (CRMF) payloads which provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). | |||||||||||||
| draft-ietf-lamps-dilithium-certificates-05.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA | ||||||||||||||
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. | |||||||||||||
| draft-ietf-lamps-e2e-mail-guidance-16.txt | ||||||||||||||
| Guidance on End-to-End E-mail Security | ||||||||||||||
|
End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers to help mitigate those risks, and to make end-to-end e-mail simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems. | |||||||||||||
| draft-ietf-lamps-header-protection-24.txt | ||||||||||||||
| Header Protection for Cryptographically Protected E-mail | ||||||||||||||
|
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections. | |||||||||||||
| draft-ietf-lamps-im-keyusage-04.txt | ||||||||||||||
| X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs | ||||||||||||||
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates | |||||||||||||
| draft-ietf-lamps-kyber-certificates-06.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) | ||||||||||||||
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also described. | |||||||||||||
| draft-ietf-lamps-pq-composite-kem-05.txt | ||||||||||||||
| Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS | ||||||||||||||
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-KEM is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [RFC9629]. | |||||||||||||
| draft-ietf-lamps-pq-composite-sigs-03.txt | ||||||||||||||
| Composite ML-DSA For use in X.509 Public Key Infrastructure and CMS | ||||||||||||||
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. | |||||||||||||
| draft-ietf-lamps-rfc4210bis-15.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) | ||||||||||||||
|
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of KEM certificates and use EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. The updates maintain backward compatibility with CMP version 2 wherever possible. Updates to CMP version 2 are improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. CMP version 3 is introduced for changes to the ASN.1 syntax, which are support of EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann messages. This document obsoletes RFC 4210 and together with I-D.ietf-lamps- rfc6712bis and it also obsoletes RFC 9480. Appendix F of this document updates the Section 9 of RFC 5912. | |||||||||||||
| draft-ietf-lamps-rfc5019bis-12.txt | ||||||||||||||
| Updates to Lightweight OCSP Profile for High Volume Environments | ||||||||||||||
|
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1. | |||||||||||||
| draft-ietf-lamps-rfc5272bis-01.txt | ||||||||||||||
| Certificate Management over CMS (CMC) | ||||||||||||||
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: | |||||||||||||
| draft-ietf-lamps-rfc5273bis-01.txt | ||||||||||||||
| Certificate Management over CMS (CMC): Transport Protocols | ||||||||||||||
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFCs 5273 and 6402. | |||||||||||||
| draft-ietf-lamps-rfc5274bis-01.txt | ||||||||||||||
| Certificate Management Messages over CMS (CMC): Compliance Requirements | ||||||||||||||
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFCs 5274 and 6402. | |||||||||||||
| draft-ietf-lamps-rfc5990bis-10.txt | ||||||||||||||
| Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM Algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM Algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC XXXX. This document obsoletes RFC 5990. RFC EDITOR: Please replace XXXX with the RFC number assigned to draft-ietf-lamps-cms-kemri. | |||||||||||||
| draft-ietf-lamps-rfc6712bis-09.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) | ||||||||||||||
|
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates to RFC 6712 specified in RFC 9480 Section 3. These updates introduce CMP URIs using a Well-known prefix. It obsoletes RFC 6712 and together with I-D.ietf-lamps-rfc4210bis and it also obsoletes RFC 9480. | |||||||||||||
| draft-ietf-lamps-rfc7030-csrattrs-13.txt | ||||||||||||||
| Clarification and enhancement of RFC7030 CSR Attributes definition | ||||||||||||||
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. Moreover, it provides new convenient and straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows specifying a subject Distinguished Name (DN). | |||||||||||||
| draft-ietf-lamps-rfc8708bis-03.txt | ||||||||||||||
| Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) | ||||||||||||||
|
This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC 8708. | |||||||||||||
| draft-ietf-lamps-rfc9579bis-03.txt | ||||||||||||||
| Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax | ||||||||||||||
|
This document specifies additions and amendments to RFCs 7292 and 8018. It obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. | |||||||||||||
| draft-ietf-lamps-x509-shbs-13.txt | ||||||||||||||
| Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure | ||||||||||||||
|
This document specifies algorithm identifiers and ASN.1 encoding formats for the stateful hash-based signature (HBS) schemes Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when those digital signatures are used in Internet X.509 certificates and certificate revocation lists. | |||||||||||||
| draft-ietf-lamps-x509-slhdsa-03.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA | ||||||||||||||
|
Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also described. | |||||||||||||
| draft-ietf-lisp-ecdsa-auth-13.txt | ||||||||||||||
| LISP Control-Plane ECDSA Authentication and Authorization | ||||||||||||||
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. | |||||||||||||
| draft-ietf-lisp-eid-anonymity-17.txt | ||||||||||||||
| LISP EID Anonymity | ||||||||||||||
|
This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. | |||||||||||||
| draft-ietf-lisp-eid-mobility-15.txt | ||||||||||||||
| LISP L2/L3 EID Mobility Using a Unified Control Plane | ||||||||||||||
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. | |||||||||||||
| draft-ietf-lisp-geo-08.txt | ||||||||||||||
| LISP Geo-Coordinate Use-Cases | ||||||||||||||
|
This document describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates, which is compatible with the Global Positioning Satellite (GPS) encodings used by other routing protocols. This document updates [RFC8060]. | |||||||||||||
| draft-ietf-lisp-group-mapping-01.txt | ||||||||||||||
| LISP Multicast Overlay Group to Underlay RLOC Mappings | ||||||||||||||
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. | |||||||||||||
| draft-ietf-lisp-map-server-reliable-transport-05.txt | ||||||||||||||
| LISP Map Server Reliable Transport | ||||||||||||||
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. | |||||||||||||
| draft-ietf-lisp-name-encoding-17.txt | ||||||||||||||
| LISP Distinguished Name Encoding | ||||||||||||||
|
This documents defines how to use the Address Family Identifier (AFI) 17 "Distinguished Names" in LISP. Distinguished Names can be used either in Endpoint Identifiers (EID) records or Routing Locators (RLOC) records in LISP control messages to convey additional information. | |||||||||||||
| draft-ietf-lisp-nexagon-54.txt | ||||||||||||||
| Network-Hexagons:Large-Area Dynamic Comprehension Based On H3 and LISP | ||||||||||||||
|
This document describes the use of IETF Locator/ID Separation Protocol (LISP) to enable near real-time understanding of dynamic conditions across large areas, including both on-road and off-road environments. The system is designed to function during routine operations as well as recovery scenarios. It leverages imagery feeds from various mobile sources, including low Earth orbit satellites, UAVs, drones, and vehicle cameras. By dividing geographic regions into high-resolution | |||||||||||||
| draft-ietf-lisp-predictive-rlocs-15.txt | ||||||||||||||
| LISP Predictive RLOCs | ||||||||||||||
|
This specification describes a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs. | |||||||||||||
| draft-ietf-lisp-rfc6831bis-00.txt | ||||||||||||||
| The Locator/ID Separation Protocol (LISP) for Multicast Environments | ||||||||||||||
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. | |||||||||||||
| draft-ietf-lisp-rfc8378bis-00.txt | ||||||||||||||
| Signal-Free Locator/ID Separation Protocol (LISP) Multicast | ||||||||||||||
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. | |||||||||||||
| draft-ietf-lisp-site-external-connectivity-01.txt | ||||||||||||||
| LISP Site External Connectivity | ||||||||||||||
|
This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination). | |||||||||||||
| draft-ietf-lisp-te-20.txt | ||||||||||||||
| LISP Traffic Engineering | ||||||||||||||
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. | |||||||||||||
| draft-ietf-lisp-yang-22.txt | ||||||||||||||
| LISP YANG Model | ||||||||||||||
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. | |||||||||||||
| draft-ietf-lsr-anycast-flag-01.txt | ||||||||||||||
| Updates to Anycast Property advertisement for OSPFv2 | ||||||||||||||
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. | |||||||||||||
| draft-ietf-lsr-distoptflood-07.txt | ||||||||||||||
| IS-IS Distributed Flooding Reduction | ||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. | |||||||||||||
| draft-ietf-lsr-flex-algo-bw-con-17.txt | ||||||||||||||
| Flexible Algorithms: Bandwidth,Delay,Metrics and Constraints | ||||||||||||||
|
Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. | |||||||||||||
| draft-ietf-lsr-igp-flex-algo-reverse-affinity-03.txt | ||||||||||||||
| IGP Flexible Algorithms Reverse Affinity Constraint | ||||||||||||||
|
An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. | |||||||||||||
| draft-ietf-lsr-igp-ureach-prefix-announce-03.txt | ||||||||||||||
| IGP Unreachable Prefix Announcement | ||||||||||||||
|
In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. | |||||||||||||
| draft-ietf-lsr-isis-pics-l2member-attr-yang-00.txt | ||||||||||||||
| YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS | ||||||||||||||
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. | |||||||||||||
| draft-ietf-lsr-isis-pics-srmpls-yang-00.txt | ||||||||||||||
| YANG Data Model for IS-IS Segment Routing MPLS PICS | ||||||||||||||
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. | |||||||||||||
| draft-ietf-lsr-isis-pics-yang-00.txt | ||||||||||||||
| YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) | ||||||||||||||
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). | |||||||||||||
| draft-ietf-lsr-isis-sr-vtn-mt-08.txt | ||||||||||||||
| Applicability of IS-IS Multi-Topology (MT) for Segment Routing 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 logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. | |||||||||||||
| draft-ietf-lsr-isis-srv6-yang-06.txt | ||||||||||||||
| YANG Data Model for IS-IS SRv6 | ||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. | |||||||||||||
| draft-ietf-lsr-isis-yang-augmentation-v1-08.txt | ||||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Version 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, IS-IS Application-Specific Link Attributes as defined in RFC 9479, IS-IS Flexible Algorithm as defined in RFC 9350, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. | |||||||||||||
| draft-ietf-lsr-multi-tlv-06.txt | ||||||||||||||
| Multi-part TLVs in IS-IS | ||||||||||||||
|
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. | |||||||||||||
| draft-ietf-lsr-ospf-admin-tags-23.txt | ||||||||||||||
| Extensions to OSPF for Advertising Prefix Administrative Tags | ||||||||||||||
|
It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. | |||||||||||||
| draft-ietf-lsr-ospf-ls-link-infinity-02.txt | ||||||||||||||
| Advertising Unreachable Links in OSPF | ||||||||||||||
|
In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe). | |||||||||||||
| draft-ietf-lsr-ospf-prefix-extended-flags-03.txt | ||||||||||||||
| Prefix Flag Extension for OSPFv2 and OSPFv3 | ||||||||||||||
|
Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix Attribute Flags Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. | |||||||||||||
| draft-ietf-lsr-ospf-srv6-yang-06.txt | ||||||||||||||
| YANG Data Model for OSPF SRv6 | ||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. | |||||||||||||
| draft-ietf-lsr-ospf-transport-instance-08.txt | ||||||||||||||
| OSPF-GT (Generalized Transport) | ||||||||||||||
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. | |||||||||||||
| draft-ietf-lsr-ospf-yang-augmentation-v1-13.txt | ||||||||||||||
| OSPF YANG Model Augmentations for Additional Features - Version 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm. | |||||||||||||
| draft-ietf-lsvr-applicability-15.txt | ||||||||||||||
| Usage and Applicability of Link State Vector Routing in Data Centers | ||||||||||||||
|
This document discusses the usage and applicability of BGP Link-State Shortest Path First (BGP-SPF) extensions in data center networks utilizing Clos or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of BGP-SPF extensions. | |||||||||||||
| draft-ietf-lsvr-bgp-spf-41.txt | ||||||||||||||
| BGP Link-State Shortest Path First (SPF) Routing | ||||||||||||||
|
Many Massively Scaled Data Centers (MSDCs) have converged on simplified L3 routing. Furthermore, requirements for operational simplicity has led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. | |||||||||||||
| draft-ietf-lsvr-l3dl-13.txt | ||||||||||||||
| Layer-3 Discovery and Liveness | ||||||||||||||
|
In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. | |||||||||||||
| draft-ietf-madinas-mac-address-randomization-15.txt | ||||||||||||||
| Randomized and Changing MAC Address State of Affairs | ||||||||||||||
|
Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on MAC addresses. There have been several initiatives within the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities to help coordinating standardization activities in these bodies. | |||||||||||||
| draft-ietf-madinas-use-cases-19.txt | ||||||||||||||
| Randomized and Changing MAC Address: Context,Network Impacts,and Use Cases | ||||||||||||||
|
To limit the privacy issues created by the association between a device, its traffic, its location, and its user in [IEEE_802] networks, client and client Operating System vendors have started implementing MAC address randomization. This technology is particularly important in Wi-Fi [IEEE_802.11] networks due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC address randomization purposes. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines two existing frameworks to maintain user privacy while preserving user quality of experience and network operation efficiency. | |||||||||||||
| draft-ietf-mailmaint-autoconfig-00.txt | ||||||||||||||
| Mail Autoconfig | ||||||||||||||
|
Set up a mail account with only email address and password. | |||||||||||||
| draft-ietf-mailmaint-expires-00.txt | ||||||||||||||
| Updated Use of the Expires Message Header Field | ||||||||||||||
|
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. | |||||||||||||
| draft-ietf-mailmaint-imap-uidbatches-00.txt | ||||||||||||||
| IMAP UIDBATCHES Extension | ||||||||||||||
|
The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve UIDs from the server such that these UIDs split the messages of a mailbox into equally sized batches. This lets the client perform operations such as FETCH/SEARCH/STORE on these specific batches. This limits the number of messages that each command operates on, enabling better control over resource usage and response sizes. | |||||||||||||
| draft-ietf-mailmaint-messageflag-mailboxattribute-01.txt | ||||||||||||||
| Registration of further IMAP/JMAP keywords and mailbox attribute names | ||||||||||||||
|
This document defines a number of keywords that have been in use by Fastmail and Apple respectively for some time. It defines their intended use. Additionally some mailbox names with special meaning have been in use by Fastmail, and this document defines their intended use. This document registers all of these names with IANA to avoid name collisions. | |||||||||||||
| draft-ietf-mailmaint-wrong-recipient-00.txt | ||||||||||||||
| Adding a Wrong Recipient URL for Handling Misdirected Emails | ||||||||||||||
|
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient. | |||||||||||||
| draft-ietf-manet-dlep-channel-utilization-01.txt | ||||||||||||||
| DLEP Radio Channel Utilization Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. | |||||||||||||
| draft-ietf-manet-dlep-credit-flow-control-16.txt | ||||||||||||||
| Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items | ||||||||||||||
|
This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are extensible and reusable. Their use will be mandated in other documents defining specific DLEP extensions. | |||||||||||||
| draft-ietf-manet-dlep-da-credit-extension-20.txt | ||||||||||||||
| DLEP DiffServ Aware Credit Window Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. | |||||||||||||
| draft-ietf-manet-dlep-ether-credit-extension-08.txt | ||||||||||||||
| DLEP IEEE 802.1Q Aware Credit Window Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. | |||||||||||||
| draft-ietf-manet-dlep-radio-band-01.txt | ||||||||||||||
| DLEP Radio Band Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the frequency bands used by the radio. | |||||||||||||
| draft-ietf-manet-dlep-radio-quality-01.txt | ||||||||||||||
| DLEP Radio Quality Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. | |||||||||||||
| draft-ietf-manet-dlep-traffic-classification-13.txt | ||||||||||||||
| Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item | ||||||||||||||
|
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/ packet content such as destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items, and Sub-Data Items are defined to support DiffServ and Ethernet traffic classification. | |||||||||||||
| draft-ietf-masque-connect-ethernet-05.txt | ||||||||||||||
| Proxying Ethernet in HTTP | ||||||||||||||
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. | |||||||||||||
| draft-ietf-masque-connect-ip-dns-01.txt | ||||||||||||||
| DNS Configuration for Proxying IP in HTTP | ||||||||||||||
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. | |||||||||||||
| draft-ietf-masque-connect-udp-listen-04.txt | ||||||||||||||
| Proxying Bound UDP in HTTP | ||||||||||||||
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. | |||||||||||||
| draft-ietf-masque-quic-proxy-04.txt | ||||||||||||||
| QUIC-Aware Proxying Using HTTP | ||||||||||||||
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. | |||||||||||||
| draft-ietf-mboned-amt-yang-02.txt | ||||||||||||||
| YANG Data Model for Automatic Multicast Tunneling | ||||||||||||||
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. | |||||||||||||
| draft-ietf-mboned-multicast-yang-model-11.txt | ||||||||||||||
| Multicast YANG Data Model | ||||||||||||||
|
This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. | |||||||||||||
| draft-ietf-mboned-redundant-ingress-failover-05.txt | ||||||||||||||
| Multicast Redundant Ingress Router Failover | ||||||||||||||
|
This document discusses multicast redundant ingress router failover issues, include global multicast and Service Provider Network MVPN use case. This document analyzes specification of global multicast and Multicast VPN Fast Upstream Failover and the Ingress PE Standby Modes and the benefits of each mode. | |||||||||||||
| draft-ietf-mediaman-6838bis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-mediaman-haptics-05.txt | ||||||||||||||
| The 'haptics' Top-level Media Type | ||||||||||||||
|
This memo serves to register and document the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration for a set of subtypes, which are representative of some existing subtypes already in use. | |||||||||||||
| draft-ietf-mediaman-suffixes-08.txt | ||||||||||||||
| Media Type Suffixes | ||||||||||||||
|
This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to provide additional clarifications on how to interpret and register media types with suffixes. | |||||||||||||
| draft-ietf-mediaman-toplevel-06.txt | ||||||||||||||
| Guidelines for the Definition of New Top-Level Media Types | ||||||||||||||
|
This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. [RFC Editor, please remove this paragraph.] Comments and discussion about this document should be directed to media-types@ietf.org, the mailing list of the Media Type Maintenance (mediaman) WG. Alternatively, issues can be raised on GitHub at https://github.com/ ietf-wg-mediaman/toplevel. | |||||||||||||
| draft-ietf-mimi-arch-01.txt | ||||||||||||||
| An Architecture for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. | |||||||||||||
| draft-ietf-mimi-content-05.txt | ||||||||||||||
| More Instant Messaging Interoperability (MIMI) message content | ||||||||||||||
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. | |||||||||||||
| draft-ietf-mimi-protocol-02.txt | ||||||||||||||
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS | ||||||||||||||
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. | |||||||||||||
| draft-ietf-mimi-room-policy-00.txt | ||||||||||||||
| Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol | ||||||||||||||
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. | |||||||||||||
| draft-ietf-mlcodec-opus-dred-02.txt | ||||||||||||||
| Deep Audio Redundancy (DRED) Extension for the Opus Codec | ||||||||||||||
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. | |||||||||||||
| draft-ietf-mlcodec-opus-extension-02.txt | ||||||||||||||
| Extension Formatting for the Opus Codec | ||||||||||||||
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. | |||||||||||||
| draft-ietf-mlcodec-opus-speech-coding-enhancement-00.txt | ||||||||||||||
| Integration of Speech Codec Enhancement Methods into the Opus Codec | ||||||||||||||
|
This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] | |||||||||||||
| draft-ietf-mls-architecture-15.txt | ||||||||||||||
| The Messaging Layer Security (MLS) Architecture | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) provides a Group Key Agreement protocol for messaging applications. MLS is meant to protect against eavesdropping, tampering, message forgery, and provide Forward Secrecy (FS) and Post-Compromise Security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the delivery service, or the authentication service. | |||||||||||||
| draft-ietf-mls-extensions-05.txt | ||||||||||||||
| The Messaging Layer Security (MLS) Extensions | ||||||||||||||
|
This document describes extensions to the Messaging Layer Security (MLS) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-extensions. | |||||||||||||
| draft-ietf-mops-ar-use-case-18.txt | ||||||||||||||
| Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure | ||||||||||||||
|
This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, this document discusses those applications that run on devices having different form factors (such as different physical sizes and shapes) and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. This document discusses the expected behavior of XR applications which can be used to manage the traffic. In addition, the document discusses the service requirements of XR applications to be able to run on the network. | |||||||||||||
| draft-ietf-mops-treedn-07.txt | ||||||||||||||
| TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences | ||||||||||||||
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as- a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology in the way that it makes content distribution more accessible to more people by dramatically reducing the costs of replication. | |||||||||||||
| draft-ietf-moq-catalogformat-01.txt | ||||||||||||||
| Common Catalog Format for moq-transport | ||||||||||||||
|
This specification defines a Common Catalog specification for streaming formats implementing the MOQ Transport Protocol [MoQTransport]. Media over QUIC Transport (MOQT) defines a publish/ subscribe based unified media delivery protocol for delivering media for streaming and interactive applications over QUIC. The catalog describes the content made available by a publisher, including information necessary for subscribers to select, subscribe and initialize tracks. | |||||||||||||
| draft-ietf-moq-transport-07.txt | ||||||||||||||
| Media over QUIC Transport | ||||||||||||||
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. | |||||||||||||
| draft-ietf-mpls-1stnibble-13.txt | ||||||||||||||
| IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack | ||||||||||||||
|
This document creates a new IANA registry (called the Post-stack First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document sets out some documentation requirements for registering new values, and requirements that make processing MPLS packets easier and more robust. The relationship between the IANA IP Version Numbers (RFC 2780) and the Post-stack First Nibble registry is described in this document. This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. | |||||||||||||
| draft-ietf-mpls-inband-pm-encapsulation-18.txt | ||||||||||||||
| Encapsulation For MPLS Performance Measurement with Alternate-Marking Method | ||||||||||||||
|
This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking method, which performs flow- based packet loss, delay, and jitter measurements on the MPLS traffic. | |||||||||||||
| draft-ietf-mpls-mldp-yang-12.txt | ||||||||||||||
| YANG Data Model for MPLS mLDP | ||||||||||||||
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-mpls-mna-fwk-14.txt | ||||||||||||||
| MPLS Network Actions (MNA) Framework | ||||||||||||||
|
This document describes an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions. The document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. | |||||||||||||
| draft-ietf-mpls-mna-hdr-10.txt | ||||||||||||||
| MPLS Network Action (MNA) Sub-Stack Solution | ||||||||||||||
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user- defined operations. This solution document specifies In-stack network action and In-stack data specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". This document describes an experiment whose purpose is to demonstrate that the MNA can be implemented and deployed. | |||||||||||||
| draft-ietf-mpls-mna-usecases-15.txt | ||||||||||||||
| Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data | ||||||||||||||
|
This document presents use cases that have a common feature that may be addressed by encoding network action indicators and associated ancillary data within MPLS packets. There is community interest in extending the MPLS data plane to carry such indicators and ancillary data to address the use cases that are described in this document. The use cases described in this document are not an exhaustive set, but rather the ones that are actively discussed by members of the IETF MPLS, PALS, and DetNet working groups from the beginning of work on the MPLS Network Action until the publication of this document. | |||||||||||||
| draft-ietf-mpls-msd-yang-12.txt | ||||||||||||||
| YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth | ||||||||||||||
|
This document defines two YANG data modules. The first is the initial version of the IANA-maintained YANG module for Maximum Segment Identifier (SID) Depths (MSDs) Types, which includes identities for both the MPLS and SRv6 data planes. The second augments the IETF MPLS YANG model to provide support for MPLS MSDs as defined in RFC 8476 and RFC 8491. | |||||||||||||
| draft-ietf-mpls-p2mp-bfd-08.txt | ||||||||||||||
| BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP | ||||||||||||||
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) and Segment Routing (SR) point-to- multipoint policies with SR-MPLS data plane. Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. | |||||||||||||
| draft-ietf-mpls-rfc6374-sr-17.txt | ||||||||||||||
| Performance Measurement for Segment Routing Networks with MPLS Data Plane | ||||||||||||||
|
This document specifies the application of the MPLS loss and delay measurement techniques, originally defined in RFC 6374, RFC 7876, and RFC 9341 within Segment Routing (SR) networks that utilize the MPLS data plane (SR-MPLS). Segment Routing enables the forwarding of packets through an ordered list of instructions, known as segments, which are imposed at the ingress node. This document defines the procedures and extensions necessary to perform accurate measurement of packet loss and delay in SR-MPLS environments, ensuring that network operators can effectively measure and maintain the quality of service across their SR-based MPLS networks. This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies. | |||||||||||||
| draft-ietf-mpls-ri-rsvp-frr-22.txt | ||||||||||||||
| Refresh-interval Independent FRR Facility Protection | ||||||||||||||
|
The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. | |||||||||||||
| draft-ietf-mpls-spring-inter-domain-oam-20.txt | ||||||||||||||
| Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks | ||||||||||||||
|
The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. An SR-MPLS network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes. | |||||||||||||
| draft-ietf-mpls-spring-lsp-ping-path-sid-03.txt | ||||||||||||||
| Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes | ||||||||||||||
|
Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. Path Segment can be used in an SR over MPLS (SR-MPLS) data plane. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV and sub-TLV definitions for PSID. | |||||||||||||
| draft-ietf-mpls-sr-epe-oam-19.txt | ||||||||||||||
| Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane | ||||||||||||||
|
Egress Peer Engineering (EPE) is an application of Segment Routing to solve the problem of egress peer selection. The Segment Routing based BGP-EPE solution allows a centralized controller, e.g. a Software Defined Network (SDN) controller to program any egress peer. The EPE solution requires the node or the SDN controller to program the PeerNode Segment Identifier(SID) describing a session between two nodes, the PeerAdj SID describing the link (one or more) that is used by sessions between peer nodes, and the PeerSet SID describing any connected interface to any peer in the related group. This document provides new sub-TLVs for EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and Traceroute procedures. | |||||||||||||
| draft-ietf-mpls-stamp-pw-00.txt | ||||||||||||||
| Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks | ||||||||||||||
|
Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without adding an IP/UDP header. | |||||||||||||
| draft-ietf-netconf-adaptive-subscription-06.txt | ||||||||||||||
| Adaptive Subscription to YANG Notification | ||||||||||||||
|
This document defines a YANG data model and associated mechanism that enable adaptive subscription to YANG notifications. The periodic update interval for the stream can be set adaptively. Applying adaptive subscription allows publishers to adjust the subscription period dynamically based on pre-defined threshold for finer-grained network telemetry data sent to receivers. | |||||||||||||
| draft-ietf-netconf-configuration-tracing-03.txt | ||||||||||||||
| External Trace ID for Configuration Tracing | ||||||||||||||
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. | |||||||||||||
| draft-ietf-netconf-distributed-notif-10.txt | ||||||||||||||
| Subscription to Distributed Notifications | ||||||||||||||
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. | |||||||||||||
| draft-ietf-netconf-http-client-server-23.txt | ||||||||||||||
| YANG Groupings for HTTP Clients and HTTP Servers | ||||||||||||||
|
This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Support is provided for HTTP/1.1, HTTP/2, and HTTP/3. | |||||||||||||
| draft-ietf-netconf-https-notif-15.txt | ||||||||||||||
| An HTTPS-based Transport for YANG Notifications | ||||||||||||||
|
This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. | |||||||||||||
| draft-ietf-netconf-list-pagination-05.txt | ||||||||||||||
| List Pagination for YANG-driven Protocols | ||||||||||||||
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. | |||||||||||||
| draft-ietf-netconf-list-pagination-nc-05.txt | ||||||||||||||
| NETCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the | |||||||||||||
| draft-ietf-netconf-list-pagination-rc-05.txt | ||||||||||||||
| RESTCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET and DELETE operations, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. | |||||||||||||
| draft-ietf-netconf-netconf-client-server-37.txt | ||||||||||||||
| NETCONF Client and Server Models | ||||||||||||||
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-08-14 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log | |||||||||||||
| draft-ietf-netconf-over-quic-01.txt | ||||||||||||||
| NETCONF over QUIC | ||||||||||||||
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS specified in [I-D.ietf-netconf-over-tls13]. | |||||||||||||
| draft-ietf-netconf-over-tls13-04.txt | ||||||||||||||
| Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication | ||||||||||||||
|
RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data. | |||||||||||||
| draft-ietf-netconf-privcand-05.txt | ||||||||||||||
| NETCONF Private Candidates | ||||||||||||||
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. | |||||||||||||
| draft-ietf-netconf-restconf-client-server-38.txt | ||||||||||||||
| RESTCONF Client and Server Models | ||||||||||||||
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-08-14 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log | |||||||||||||
| draft-ietf-netconf-restconf-trace-ctx-headers-04.txt | ||||||||||||||
| RESTCONF Extension to Support Trace Context Headers | ||||||||||||||
|
This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. | |||||||||||||
| draft-ietf-netconf-trace-ctx-extension-03.txt | ||||||||||||||
| NETCONF Extension to support Trace Context propagation | ||||||||||||||
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. | |||||||||||||
| draft-ietf-netconf-transaction-id-07.txt | ||||||||||||||
| Transaction ID Mechanism for NETCONF | ||||||||||||||
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. | |||||||||||||
| draft-ietf-netconf-udp-client-server-05.txt | ||||||||||||||
| YANG Groupings for UDP Clients and UDP Servers | ||||||||||||||
|
This document defines two YANG 1.1 modules to support the configuration of UDP clients and UDP servers. | |||||||||||||
| draft-ietf-netconf-udp-notif-17.txt | ||||||||||||||
| UDP-based Transport for Configured Subscriptions | ||||||||||||||
|
This document describes a UDP-based protocol for YANG notifications to collect data from network nodes. A shim header is proposed to facilitate the data streaming directly from the publishing process on network processor of line cards to receivers. The objective is to provide a lightweight approach to enable higher frequency and less performance impact on publisher and receiver processes compared to already established notification mechanisms. | |||||||||||||
| draft-ietf-netconf-yang-library-augmentedby-01.txt | ||||||||||||||
| Augmented-by Addition into the IETF-YANG-Library | ||||||||||||||
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining the entire dependencies between YANG modules, by directly querying the server's YANG module. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. | |||||||||||||
| draft-ietf-netconf-yang-notifications-versioning-06.txt | ||||||||||||||
| Support of Versioning in YANG Notifications Subscription | ||||||||||||||
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. | |||||||||||||
| draft-ietf-netmod-acl-extensions-13.txt | ||||||||||||||
| Extensions to the Access Control Lists (ACLs) YANG Model | ||||||||||||||
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. | |||||||||||||
| draft-ietf-netmod-immutable-flag-02.txt | ||||||||||||||
| YANG Metadata Annotation for Immutable Flag | ||||||||||||||
|
This document defines a way to formally document an existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not proscriptive, dictating server behaviors. This document updates [RFC6241], [RFC8040], and [RFC8526]. | |||||||||||||
| draft-ietf-netmod-intf-ext-yang-14.txt | ||||||||||||||
| Common Interface Extension YANG Data Models | ||||||||||||||
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| draft-ietf-netmod-rfc6991-bis-17.txt | ||||||||||||||
| Common YANG Data Types | ||||||||||||||
|
This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. | |||||||||||||
| draft-ietf-netmod-rfc8407bis-21.txt | ||||||||||||||
| Guidelines for Authors and Reviewers of Documents Containing YANG Data Models | ||||||||||||||
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. | |||||||||||||
| draft-ietf-netmod-schedule-yang-03.txt | ||||||||||||||
| A Common YANG Data Model for Scheduling | ||||||||||||||
|
This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes a set of recurrence related groupings with varying granularity levels (i.e., from basic to advanced). | |||||||||||||
| draft-ietf-netmod-sub-intf-vlan-model-11.txt | ||||||||||||||
| Sub-interface VLAN YANG Data Models | ||||||||||||||
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orignating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| draft-ietf-netmod-syslog-model-33.txt | ||||||||||||||
| A YANG Data Model for Syslog Configuration | ||||||||||||||
|
This document defines a YANG data model for the configuration of a syslog process. It is intended that this model be used by vendors who implement syslog collectors in their systems. | |||||||||||||
| draft-ietf-netmod-system-config-10.txt | ||||||||||||||
| System-defined Configuration | ||||||||||||||
|
The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This document introduces the concept of system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients. This document updates RFC 8342. | |||||||||||||
| draft-ietf-netmod-yang-module-filename-00.txt | ||||||||||||||
| YANG module file name convention | ||||||||||||||
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. | |||||||||||||
| draft-ietf-netmod-yang-module-versioning-12.txt | ||||||||||||||
| Updated YANG Module Revision Handling | ||||||||||||||
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. | |||||||||||||
| draft-ietf-netmod-yang-packages-04.txt | ||||||||||||||
| YANG Packages | ||||||||||||||
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. It describes how packages: are represented on a server, can be defined in offline YANG instance data files, and can be used to define the content schema associated with YANG instance data files. | |||||||||||||
| draft-ietf-netmod-yang-semver-17.txt | ||||||||||||||
| YANG Semantic Versioning | ||||||||||||||
|
This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 8407, and 8525. | |||||||||||||
| draft-ietf-netmod-yang-versioning-reqs-10.txt | ||||||||||||||
| YANG Module Versioning Requirements | ||||||||||||||
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. | |||||||||||||
| draft-ietf-nfsv4-delstid-08.txt | ||||||||||||||
| Extending the Opening of Files in NFSv4.2 | ||||||||||||||
|
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This delegation provides the client the right to authoritatively cache metadata on the file locally. This document presents several extensions for both the opening and delegating of the file to the client. This document extends NFSv4.2 (see RFC7863). | |||||||||||||
| draft-ietf-nfsv4-internationalization-11.txt | ||||||||||||||
| Internationalization for the NFSv4 Protocols | ||||||||||||||
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. | |||||||||||||
| draft-ietf-nfsv4-layoutwcc-05.txt | ||||||||||||||
| Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type | ||||||||||||||
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server to changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server. | |||||||||||||
| draft-ietf-nfsv4-layrec-04.txt | ||||||||||||||
| Reporting of Errors via LAYOUTRETURN in NFSv4.2 | ||||||||||||||
|
The Parallel Network File System (pNFS) allows for a file's metadata (MDS) and data (DS) to be on different servers. When the metadata server is restarted, the client can still modify the data file component. During the recovery phase of startup, the metadata server and the data servers work together to recover state (which files are open, last modification time, size, etc.). If the client has not encountered errors with the data files, then the state can be recovered, avoiding resilvering of the data files. With any errors, there is no means by which the client can report errors to the metadata server. As such, the metadata server has to assume that file needs resilvering. This document presents an extension to RFC8435 to allow the client to update the metadata and avoid the resilvering. | |||||||||||||
| draft-ietf-nfsv4-rfc5661bis-09.txt | ||||||||||||||
| Network File System (NFS) Version 4 Minor Version 1 Protocol | ||||||||||||||
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. | |||||||||||||
| draft-ietf-nmop-network-anomaly-architecture-01.txt | ||||||||||||||
| An Architecture for a Network Anomaly Detection Framework | ||||||||||||||
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is generic applicable and extensible. Different applications are being described and exampled with open-source running code. | |||||||||||||
| draft-ietf-nmop-network-anomaly-lifecycle-00.txt | ||||||||||||||
| An Experiment: Network Anomaly Lifecycle | ||||||||||||||
|
Network Anomaly Detection is the act of detecting problems in the network. Accurately detect problems is very challenging for network operators in production networks. Good results require a lot of expertise and knowledge around both the implied network technologies and the connectivity services provided to customers, apart from a proper monitoring infrastructure. In order to facilitate network anomaly detection, novel techniques are being introduced, including programmatical, rule-based and AI-based, with the promise of improving scalability and the hope to keep a high detection accuracy. To guarantee acceptable results, the process needs to be properly designed, adopting well-defined stages to accurately collect evidence of anomalies, validate their relevancy and improve the detection systems over time, iteratively. This document describes a well-defined approach on managing the lifecycle process of a network anomaly detection system, spanning across the recording of its output and its iterative refinement, in order to facilitate network engineers to interact with the network anomaly detection system, enable the "human-in-the-loop" paradigm and refine the detection abilities over time. The major contributions of this document are: the definition of three key stages of the lifecycle process, the definition of a state machine for each anomaly annotation on the system and the definition of YANG data models describing a comprehensive format for the anomaly labels, allowing a well-structured exchange of those between all the interested actors. | |||||||||||||
| draft-ietf-nmop-network-anomaly-semantics-00.txt | ||||||||||||||
| Semantic Metadata Annotation for Network Anomaly Detection | ||||||||||||||
|
This document explains why and how semantic metadata annotation helps to test, validate and compare Outlier and Symptom detection, supports supervised and semi-supervised machine learning development, enables data exchange among network operators, vendors and academia and make anomalies for humans apprehensible. The proposed semantics uniforms the network anomaly data exchange between and among operators and vendors to improve their Service Disruption Detection Systems. | |||||||||||||
| draft-ietf-nmop-network-incident-yang-02.txt | ||||||||||||||
| A YANG Data Model for Network Incident Management | ||||||||||||||
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and root cause analysis. | |||||||||||||
| draft-ietf-nmop-simap-concept-00.txt | ||||||||||||||
| SIMAP: Concept,Requirements,and Use Cases | ||||||||||||||
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map in the old draft versions (draft-ietf-nmop-digital-map-concept). The document intends to be used as a reference for the assessment effort of the various topology modules to meet SIMAP requirements. | |||||||||||||
| draft-ietf-nmop-terminology-09.txt | ||||||||||||||
| Some Key Terms for Network Fault and Problem Management | ||||||||||||||
|
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG models and management protocols that report, make visible, or manage network faults and problems. | |||||||||||||
| draft-ietf-nmop-yang-message-broker-integration-05.txt | ||||||||||||||
| An Architecture for YANG-Push to Message Broker Integration | ||||||||||||||
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. | |||||||||||||
| draft-ietf-ntp-interleaved-modes-08.txt | ||||||||||||||
| NTP Interleaved Modes | ||||||||||||||
|
This document specifies interleaved modes for the Network Time Protocol (NTP), which improve the accuracy of time synchronization by enabling use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes. | |||||||||||||
| draft-ietf-ntp-ntpv5-02.txt | ||||||||||||||
| Network Time Protocol Version 5 | ||||||||||||||
|
This document describes the version 5 of the Network Time Protocol (NTP). | |||||||||||||
| draft-ietf-ntp-nts-for-ptp-00.txt | ||||||||||||||
| NTS4PTP - Network Time Security for the Precision Time Protocol | ||||||||||||||
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all relevant PTP modes and operates completely independent of NTPv4. | |||||||||||||
| draft-ietf-ntp-roughtime-12.txt | ||||||||||||||
| Roughtime | ||||||||||||||
|
This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. | |||||||||||||
| draft-ietf-ntp-update-registries-16.txt | ||||||||||||||
| Updating the NTP Registries | ||||||||||||||
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries, and makes updates where necessary. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. | |||||||||||||
| draft-ietf-nvo3-geneve-oam-13.txt | ||||||||||||||
| Active OAM for use in GENEVE | ||||||||||||||
|
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol designed to encapsulate network packets for transport across underlying physical networks. This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks. It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol to support network operators in maintaining reliable and efficient virtualized network environments. | |||||||||||||
| draft-ietf-oauth-attestation-based-client-auth-04.txt | ||||||||||||||
| OAuth 2.0 Attestation-Based Client Authentication | ||||||||||||||
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. | |||||||||||||
| draft-ietf-oauth-browser-based-apps-20.txt | ||||||||||||||
| OAuth 2.0 for Browser-Based Applications | ||||||||||||||
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. | |||||||||||||
| draft-ietf-oauth-cross-device-security-08.txt | ||||||||||||||
| Cross-Device Flows: Security Best Current Practice | ||||||||||||||
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. | |||||||||||||
| draft-ietf-oauth-first-party-apps-00.txt | ||||||||||||||
| OAuth 2.0 for First-Party Applications | ||||||||||||||
|
This document defines the Authorization Challenge Endpoint, which supports a first-party client that wants to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions. | |||||||||||||
| draft-ietf-oauth-identity-chaining-02.txt | ||||||||||||||
| OAuth Identity and Authorization Chaining Across Domains | ||||||||||||||
|
This specification defines a mechanism to preserve identity information and federate authorization across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. | |||||||||||||
| draft-ietf-oauth-jwt-introspection-response-12.txt | ||||||||||||||
| JWT Response for OAuth Token Introspection | ||||||||||||||
|
This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. | |||||||||||||
| draft-ietf-oauth-resource-metadata-13.txt | ||||||||||||||
| OAuth 2.0 Protected Resource Metadata | ||||||||||||||
|
This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. | |||||||||||||
| draft-ietf-oauth-sd-jwt-vc-08.txt | ||||||||||||||
| SD-JWT-based Verifiable Credentials (SD-JWT VC) | ||||||||||||||
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. | |||||||||||||
| draft-ietf-oauth-security-topics-29.txt | ||||||||||||||
| OAuth 2.0 Security Best Current Practice | ||||||||||||||
|
This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFC 6749, RFC 6750, and RFC 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. | |||||||||||||
| draft-ietf-oauth-selective-disclosure-jwt-14.txt | ||||||||||||||
| Selective Disclosure for JWTs (SD-JWT) | ||||||||||||||
|
This specification defines a mechanism for the selective disclosure of individual elements of a JSON-encoded data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. | |||||||||||||
| draft-ietf-oauth-status-list-06.txt | ||||||||||||||
| Token Status List | ||||||||||||||
|
This specification defines a mechanism, data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. | |||||||||||||
| draft-ietf-oauth-transaction-tokens-03.txt | ||||||||||||||
| Transaction Tokens | ||||||||||||||
|
Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to optionally immutably assert to downstream workloads that they were invoked in the call chain of the request. | |||||||||||||
| draft-ietf-oauth-v2-1-12.txt | ||||||||||||||
| The OAuth 2.1 Authorization Framework | ||||||||||||||
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. | |||||||||||||
| draft-ietf-ohai-chunked-ohttp-03.txt | ||||||||||||||
| Chunked Oblivious HTTP Messages | ||||||||||||||
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. | |||||||||||||
| draft-ietf-openpgp-persistent-symmetric-keys-00.txt | ||||||||||||||
| Persistent Symmetric Keys in OpenPGP | ||||||||||||||
|
This document defines new algorithms for the OpenPGP standard (RFC4880) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for authentication with hash-based message authentication codes (HMAC). This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. | |||||||||||||
| draft-ietf-openpgp-pqc-06.txt | ||||||||||||||
| Post-Quantum Cryptography in OpenPGP | ||||||||||||||
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. | |||||||||||||
| draft-ietf-openpgp-replacementkey-02.txt | ||||||||||||||
| OpenPGP Key Replacement | ||||||||||||||
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. | |||||||||||||
| draft-ietf-opsawg-ac-lxsm-lxnm-glue-12.txt | ||||||||||||||
| A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits | ||||||||||||||
|
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to Attachment Circuits (ACs) that are created using the AC service ("ietf-ac-svc") and network ("ietf-ac-ntw") models. | |||||||||||||
| draft-ietf-opsawg-collected-data-manifest-05.txt | ||||||||||||||
| A Data Manifest for Contextualized Telemetry Data | ||||||||||||||
|
Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. | |||||||||||||
| draft-ietf-opsawg-discardmodel-04.txt | ||||||||||||||
| An Information Model for Packet Discard Reporting | ||||||||||||||
|
The primary function of a network is to transport and deliver packets according to service level objectives. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Device-reported packet loss provides the most direct signal for network operations to identify the customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss. | |||||||||||||
| draft-ietf-opsawg-ipfix-alt-mark-01.txt | ||||||||||||||
| IP Flow Information Export (IPFIX) Alternate-Marking Information Elements | ||||||||||||||
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. | |||||||||||||
| draft-ietf-opsawg-ipfix-fixes-12.txt | ||||||||||||||
| Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry | ||||||||||||||
|
This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) Entities registry. Specifically, this document provides updates to fix shortcomings in the description of some Information Elements (IE), updates to ensure a consistent structure when citing an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. | |||||||||||||
| draft-ietf-opsawg-ipfix-gtpu-02.txt | ||||||||||||||
| Export of GTP-U Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. | |||||||||||||
| draft-ietf-opsawg-ipfix-on-path-telemetry-14.txt | ||||||||||||||
| Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) | ||||||||||||||
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay on the OAM transit and decapsulating nodes. | |||||||||||||
| draft-ietf-opsawg-ipfix-tcpo-v6eh-18.txt | ||||||||||||||
| Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements | ||||||||||||||
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. | |||||||||||||
| draft-ietf-opsawg-mud-acceptable-urls-12.txt | ||||||||||||||
| Authorized update to MUD URLs | ||||||||||||||
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls | |||||||||||||
| draft-ietf-opsawg-mud-iot-dns-considerations-19.txt | ||||||||||||||
| Operational Considerations for Use of DNS in IoT Devices | ||||||||||||||
|
This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying RFC 8520 Manufacturer Usage Description (MUD) definitions to control device access. Also, this document makes recommendations on when and how to use DNS names in MUD files. | |||||||||||||
| draft-ietf-opsawg-mud-tls-18.txt | ||||||||||||||
| Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices | ||||||||||||||
|
This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint. | |||||||||||||
| draft-ietf-opsawg-ntw-attachment-circuit-14.txt | ||||||||||||||
| A Network YANG Data Model for Attachment Circuits | ||||||||||||||
|
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). | |||||||||||||
| draft-ietf-opsawg-oam-characterization-04.txt | ||||||||||||||
| Guidelines for Characterizing "OAM" | ||||||||||||||
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. | |||||||||||||
| draft-ietf-opsawg-ol-07.txt | ||||||||||||||
| Ownership and licensing statements in YANG | ||||||||||||||
|
This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. | |||||||||||||
| draft-ietf-opsawg-pcap-04.txt | ||||||||||||||
| PCAP Capture File Format | ||||||||||||||
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. | |||||||||||||
| draft-ietf-opsawg-pcaplinktype-08.txt | ||||||||||||||
| Link-Layer Types for PCAP and PCAPNG Capture File Formats | ||||||||||||||
|
This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. | |||||||||||||
| draft-ietf-opsawg-pcapng-02.txt | ||||||||||||||
| PCAP Next Generation (pcapng) Capture File Format | ||||||||||||||
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. | |||||||||||||
| draft-ietf-opsawg-secure-tacacs-yang-04.txt | ||||||||||||||
| A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) | ||||||||||||||
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. | |||||||||||||
| draft-ietf-opsawg-tacacs-tls13-16.txt | ||||||||||||||
| Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 | ||||||||||||||
|
The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized TACACS+ Servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC8907. | |||||||||||||
| draft-ietf-opsawg-teas-attachment-circuit-18.txt | ||||||||||||||
| YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) | ||||||||||||||
|
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. | |||||||||||||
| draft-ietf-opsawg-teas-common-ac-13.txt | ||||||||||||||
| A Common YANG Data Model for Attachment Circuits | ||||||||||||||
|
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. | |||||||||||||
| draft-ietf-opsawg-tsvwg-udp-ipfix-14.txt | ||||||||||||||
| Export of UDP Options Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. | |||||||||||||
| draft-ietf-opsawg-ucl-acl-06.txt | ||||||||||||||
| A YANG Data Model and RADIUS Extension for Policy-based Network Access Control | ||||||||||||||
|
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. | |||||||||||||
| draft-ietf-ospf-sr-yang-32.txt | ||||||||||||||
| A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane | ||||||||||||||
|
This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. | |||||||||||||
| draft-ietf-pals-ple-14.txt | ||||||||||||||
| Private Line Emulation over Packet Switched Networks | ||||||||||||||
|
This document expands the applicability of virtual private wire services (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over packet switched networks (PSN). | |||||||||||||
| draft-ietf-payload-vp9-16.txt | ||||||||||||||
| RTP Payload Format for VP9 Video | ||||||||||||||
|
This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. | |||||||||||||
| draft-ietf-pce-bier-te-01.txt | ||||||||||||||
| PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (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. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE). | |||||||||||||
| draft-ietf-pce-circuit-style-pcep-extensions-07.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies | ||||||||||||||
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. | |||||||||||||
| draft-ietf-pce-controlled-id-space-01.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. | |||||||||||||
| draft-ietf-pce-entropy-label-position-02.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions | ||||||||||||||
|
Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. | |||||||||||||
| draft-ietf-pce-flexible-grid-11.txt | ||||||||||||||
| PCEP Extension for Flexible Grid Networks | ||||||||||||||
|
This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. | |||||||||||||
| draft-ietf-pce-iana-update-03.txt | ||||||||||||||
| Update to the IANA PCE Communication Protocol (PCEP) Registration Procedures and Allowing Experimental Error Codes | ||||||||||||||
|
This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers" group of registries. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC 8126. This memo updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604 for the same. Designating "experimental use" sub-ranges within code point registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not. This document updates RFC 5440 by designating a specific range of PCEP Error-Types for Experimental Use. | |||||||||||||
| draft-ietf-pce-multipath-12.txt | ||||||||||||||
| PCEP Extensions for Signaling Multipath Information | ||||||||||||||
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new PCEP mechanisms are meant to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. | |||||||||||||
| draft-ietf-pce-pcep-color-06.txt | ||||||||||||||
| Path Computation Element Protocol(PCEP) Extension for Color | ||||||||||||||
|
Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g. low latency). This document specifies extensions to Path Computation Element Protocol (PCEP) to carry the color attribute. | |||||||||||||
| draft-ietf-pce-pcep-extension-native-ip-40.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks | ||||||||||||||
|
This document introduces extensions to the PCE Communication Protocol (PCEP) to support path computation in native IP networks through a PCE-based central control mechanism known as Centralized Control Dynamic Routing (CCDR). These extensions empower a PCE to calculate and manage paths specifically for native IP networks, expand PCEP’s capabilities beyond its traditional use in MPLS and GMPLS networks. By implementing these extensions, IP network resources can be utilized more efficiently, facilitating the deployment of traffic engineering in native IP environments. | |||||||||||||
| draft-ietf-pce-pcep-extension-pce-controller-sr-09.txt | ||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. | ||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. | |||||||||||||
| draft-ietf-pce-pcep-extension-pce-controller-srv6-03.txt | ||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. | ||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. Each path is specified as a set of "segments" encoded in the header of each packet as a list of Segment Identifiers (SIDs). This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in the SRv6 (SR in IPv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID allocation and distribution. | |||||||||||||
| draft-ietf-pce-pcep-ifit-05.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. | |||||||||||||
| draft-ietf-pce-pcep-l2-flowspec-07.txt | ||||||||||||||
| PCEP Extension for Layer 2 (L2) Flow Specification | ||||||||||||||
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. | |||||||||||||
| draft-ietf-pce-pcep-ls-02.txt | ||||||||||||||
| PCEP extensions for Distribution of Link-State and TE Information | ||||||||||||||
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. | |||||||||||||
| draft-ietf-pce-pcep-pmtu-06.txt | ||||||||||||||
| Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available at the headend. This document specify the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR and other scenarios. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. | |||||||||||||
| draft-ietf-pce-pcep-srv6-yang-06.txt | ||||||||||||||
| A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) | ||||||||||||||
|
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). | |||||||||||||
| draft-ietf-pce-pcep-yang-28.txt | ||||||||||||||
| A YANG Data Model for Path Computation Element Communications Protocol (PCEP) | ||||||||||||||
|
This document defines a YANG data model for the management of the Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. | |||||||||||||
| draft-ietf-pce-pceps-tls13-04.txt | ||||||||||||||
| Updates for PCEPS: TLS Connection Establishment Restrictions | ||||||||||||||
|
Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data. | |||||||||||||
| draft-ietf-pce-segment-routing-policy-cp-18.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths | ||||||||||||||
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of the SR Policy. Additionally, this document updates RFC 8231 to allow stateful bring up of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). | |||||||||||||
| draft-ietf-pce-sid-algo-16.txt | ||||||||||||||
| Carrying SR-Algorithm Information in PCE-based Networks. | ||||||||||||||
|
The SR-Algorithm associated with a Segment-ID (SID) defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers, such as the Path Computation Element (PCE), via topology learning. This document proposes an approach for informing headend routers regarding the SR- Algorithm associated with each SID used in PCE-computed paths, as well as signaling a specific SR-Algorithm as a constraint to the PCE. | |||||||||||||
| draft-ietf-pce-sr-bidir-path-14.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. | |||||||||||||
| draft-ietf-pce-sr-p2mp-policy-09.txt | ||||||||||||||
| PCEP extensions for p2mp sr policy | ||||||||||||||
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. | |||||||||||||
| draft-ietf-pce-sr-path-segment-12.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) | ||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. | |||||||||||||
| draft-ietf-pce-state-sync-10.txt | ||||||||||||||
| Procedures for Communication between Stateful Path Computation Elements | ||||||||||||||
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. | |||||||||||||
| draft-ietf-pce-stateful-interdomain-05.txt | ||||||||||||||
| PCEP Extension for Stateful Inter-Domain Tunnels | ||||||||||||||
|
This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the MPLS toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, new PCEP communication Protocol (PCEP) Capability, new PCE Errors Type and new PCE Notifications Type. | |||||||||||||
| draft-ietf-pce-stateful-pce-autobw-update-01.txt | ||||||||||||||
| Update to Automatic Bandwidth Adjustment procedure of Stateful PCE | ||||||||||||||
|
Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to explicitly remove an attribute identified by the sub- TLV. This document updates RFC 8733 by defining the behaviour to explicitly remove an attribute. | |||||||||||||
| draft-ietf-pce-stateful-pce-optional-13.txt | ||||||||||||||
| Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects | ||||||||||||||
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. | |||||||||||||
| draft-ietf-pce-stateful-pce-vendor-13.txt | ||||||||||||||
| Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. | ||||||||||||||
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor- specific information in stateful PCE operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor-specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in stateless PCE Communication Protocol (PCEP) messages. This document extends this capability for the Stateful PCEP messages. This document updates RFC 7470 to revise the reference to the IANA registry for managing Enterprise Numbers. | |||||||||||||
| draft-ietf-pim-3228bis-07.txt | ||||||||||||||
| IANA Considerations for Internet Group Management Protocols | ||||||||||||||
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols. | |||||||||||||
| draft-ietf-pim-3376bis-12.txt | ||||||||||||||
| Internet Group Management Protocol,Version 3 | ||||||||||||||
|
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. It is a revised version of the specification to include clarifications and fixes for errata in RFC 3376 and is backwards compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. | |||||||||||||
| draft-ietf-pim-3810bis-12.txt | ||||||||||||||
| Multicast Listener Discovery Version 2 (MLDv2) for IPv6 | ||||||||||||||
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. | |||||||||||||
| draft-ietf-pim-bdr-02.txt | ||||||||||||||
| PIM Backup Designated Router Procedure | ||||||||||||||
|
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it. | |||||||||||||
| draft-ietf-pim-evpn-multicast-yang-02.txt | ||||||||||||||
| Yang Data Model for EVPN multicast | ||||||||||||||
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. | |||||||||||||
| draft-ietf-pim-gaap-02.txt | ||||||||||||||
| Group Address Allocation Protocol (GAAP) | ||||||||||||||
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. | |||||||||||||
| draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-05.txt | ||||||||||||||
| IGMP and MLD Snooping Yang Module Extension for L2VPN | ||||||||||||||
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. | |||||||||||||
| draft-ietf-pim-ipv6-zeroconf-assignment-02.txt | ||||||||||||||
| Zero-Configuration Assignment of IPv6 Multicast Addresses | ||||||||||||||
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a reserved range and prevent collisions by using mDNS to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim- zeroconf-mcast-addr-alloc-ps. | |||||||||||||
| draft-ietf-pim-jp-extensions-lisp-08.txt | ||||||||||||||
| PIM Join/Prune Attributes for LISP Environments using Underlay Multicast | ||||||||||||||
|
This document specifies an update to the PIM Receiver RLOC Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059. | |||||||||||||
| draft-ietf-pim-light-11.txt | ||||||||||||||
| Protocol Independent Multicast Light (PIM Light) | ||||||||||||||
|
This document specifies Protocol Independent Multicast Light (PIM Light) and PIM Light Interface (PLI) which does not need PIM Hello message to accept PIM Join/Prune messages. PLI can signal multicast states over networks that can not support full PIM neighbor discovery, as an example BIER networks that are connecting two or more PIM domains. This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers. | |||||||||||||
| draft-ietf-pim-mofrr-tilfa-07.txt | ||||||||||||||
| Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute | ||||||||||||||
|
This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA mechanism is designed for standard link-state Interior Gateway Protocol (IGP) shortest path and Segment Routing (SR) scenarios. TI- LFA provides fast reroute protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of fast reroute mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines the necessary protocol extensions and operational considerations to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure. This document uses the backup path computed by TI-LFA through IGP as a secondary Upstream Multicast Hop (UMH) for PIM. By using the TI-LFA backup path to send PIM secondary join messages hop- by-hop, it achieves the generation of a fast reroute backup path for PIM multicast. | |||||||||||||
| draft-ietf-pim-multicast-lessons-learned-04.txt | ||||||||||||||
| Multicast Lessons Learned from Decades of Deployment Experience | ||||||||||||||
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. | |||||||||||||
| draft-ietf-pim-multipath-igmpmldproxy-01.txt | ||||||||||||||
| Multipath Support for IGMP/MLD Proxy | ||||||||||||||
|
This document describes multipath support for Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as subscriber information, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. | |||||||||||||
| draft-ietf-pim-p2mp-policy-ping-08.txt | ||||||||||||||
| P2MP Policy Ping | ||||||||||||||
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs). | |||||||||||||
| draft-ietf-pim-pfm-forwarding-enhancements-01.txt | ||||||||||||||
| PIM Flooding Mechanism and Source Discovery Enhancements | ||||||||||||||
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM-SD deployments. | |||||||||||||
| draft-ietf-pim-rfc1112bis-02.txt | ||||||||||||||
| Host Extensions for "Any Source" IP Multicasting (ASM) | ||||||||||||||
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support Any Source Multicast (ASM) IP Multicasting or abbreviated IP Multicast. Distribution of this memo is unlimited. This document replaces [RFC1112] for anything but its specification of the IGMP version 1 protocol. | |||||||||||||
| draft-ietf-pim-sr-p2mp-policy-10.txt | ||||||||||||||
| Segment Routing Point-to-Multipoint Policy | ||||||||||||||
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments. A SR Point-to-Multipoint (SR P2MP) Policy defines a P2MP tree and a PCE computes and instantiates the tree. | |||||||||||||
| draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-03.txt | ||||||||||||||
| Updates to Dynamic IPv6 Multicast Address Group IDs | ||||||||||||||
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). | |||||||||||||
| draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-02.txt | ||||||||||||||
| Zeroconf Multicast Address Allocation Problem Statement and Requirements | ||||||||||||||
|
This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. | |||||||||||||
| draft-ietf-ppm-dap-13.txt | ||||||||||||||
| Distributed Aggregation Protocol for Privacy Preserving Measurement | ||||||||||||||
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. | |||||||||||||
| draft-ietf-ppm-dap-taskprov-01.txt | ||||||||||||||
| Task Binding and In-Band Provisioning for DAP | ||||||||||||||
|
An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. | |||||||||||||
| draft-ietf-pquip-hybrid-signature-spectrums-05.txt | ||||||||||||||
| Hybrid signature spectrums | ||||||||||||||
|
This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums | |||||||||||||
| draft-ietf-pquip-pqc-engineers-06.txt | ||||||||||||||
| Post-Quantum Cryptography for Engineers | ||||||||||||||
|
The advent of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both classical and quantum attacks. This document explains why engineers need to be aware of and understand post- quantum cryptography, detailing the impact of CRQCs on existing systems and the challenges involved in transitioning. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. | |||||||||||||
| draft-ietf-pquip-pqt-hybrid-terminology-05.txt | ||||||||||||||
| Terminology for Post-Quantum Traditional Hybrid Schemes | ||||||||||||||
|
One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. | |||||||||||||
| draft-ietf-privacypass-auth-scheme-extensions-01.txt | ||||||||||||||
| The PrivateToken HTTP Authentication Scheme Extensions Parameter | ||||||||||||||
|
This document specifies new parameters for the "PrivateToken" HTTP authentication scheme. This purpose of these parameters is to negotiate and carry extensions for Privacy Pass protocols that support public metadata. | |||||||||||||
| draft-ietf-privacypass-batched-tokens-03.txt | ||||||||||||||
| Batched Token Issuance Protocol | ||||||||||||||
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. | |||||||||||||
| draft-ietf-privacypass-public-metadata-issuance-01.txt | ||||||||||||||
| Privacy Pass Issuance Protocols with Public Metadata | ||||||||||||||
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. | |||||||||||||
| draft-ietf-quic-ack-frequency-10.txt | ||||||||||||||
| QUIC Acknowledgment Frequency | ||||||||||||||
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. | |||||||||||||
| draft-ietf-quic-multipath-11.txt | ||||||||||||||
| Multipath Extension for QUIC | ||||||||||||||
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. | |||||||||||||
| draft-ietf-quic-qlog-h3-events-09.txt | ||||||||||||||
| HTTP/3 qlog event definitions | ||||||||||||||
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). | |||||||||||||
| draft-ietf-quic-qlog-main-schema-10.txt | ||||||||||||||
| qlog: Structured Logging for Network Protocols | ||||||||||||||
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). | |||||||||||||
| draft-ietf-quic-qlog-quic-events-09.txt | ||||||||||||||
| QUIC event definitions for qlog | ||||||||||||||
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). | |||||||||||||
| draft-ietf-radext-deprecating-radius-05.txt | ||||||||||||||
| Deprecating Insecure Practices in RADIUS | ||||||||||||||
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The recent publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give recommendations for practices which increase both security and privacy. | |||||||||||||
| draft-ietf-radext-radiusdtls-bis-03.txt | ||||||||||||||
| (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS | ||||||||||||||
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. | |||||||||||||
| draft-ietf-radext-radiusv11-11.txt | ||||||||||||||
| RADIUS/1.1,Leveraging ALPN to remove MD5 | ||||||||||||||
|
This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS, called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/ TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet authentication and attribute obfuscation methods are removed. This document updates RFC2865, RFC2866, RFC5176, RFC6613, RFC6614, and RFC 7360. | |||||||||||||
| draft-ietf-radext-tls-psk-11.txt | ||||||||||||||
| Operational Considerations for RADIUS and TLS-PSK | ||||||||||||||
|
This document provides implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the RADIUS/UDP to RADIUS/TLS. | |||||||||||||
| draft-ietf-rats-ar4si-07.txt | ||||||||||||||
| Attestation Results for Secure Interactions | ||||||||||||||
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. | |||||||||||||
| draft-ietf-rats-corim-06.txt | ||||||||||||||
| Concise Reference Integrity Manifest | ||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. 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 not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. | |||||||||||||
| draft-ietf-rats-daa-06.txt | ||||||||||||||
| Direct Anonymous Attestation for the Remote Attestation Procedures Architecture | ||||||||||||||
|
This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. | |||||||||||||
| draft-ietf-rats-eat-31.txt | ||||||||||||||
| The Entity Attestation Token (EAT) | ||||||||||||||
|
An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. | |||||||||||||
| draft-ietf-rats-eat-measured-component-00.txt | ||||||||||||||
| EAT Measured Component | ||||||||||||||
|
A measured component is a measurable object of an attester's target environment, that is, an object whose state can be sampled and digested. Examples of measured components include the invariant part of firmware that is loaded in memory at startup time, a run-time integrity check, a file system object, or a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. | |||||||||||||
| draft-ietf-rats-eat-media-type-12.txt | ||||||||||||||
| EAT Media Types | ||||||||||||||
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). | |||||||||||||
| draft-ietf-rats-endorsements-05.txt | ||||||||||||||
| RATS Endorsements | ||||||||||||||
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. | |||||||||||||
| draft-ietf-rats-epoch-markers-00.txt | ||||||||||||||
| Epoch Markers | ||||||||||||||
|
This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. | |||||||||||||
| draft-ietf-rats-msg-wrap-11.txt | ||||||||||||||
| RATS Conceptual Messages Wrapper (CMW) | ||||||||||||||
|
This document defines the RATS conceptual message wrapper (CMW) format, a type of encapsulation format that can be used for any RATS messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. Additionally, the document describes a collection type that enables the aggregation of one or more CMWs into a single message. This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. In addition, a Media Type and a CoAP Content-Format are defined for transporting CMWs in HTTP, MIME, CoAP and other Internet protocols. | |||||||||||||
| draft-ietf-rats-network-device-subscription-05.txt | ||||||||||||||
| Attestation Event Stream Subscription | ||||||||||||||
|
This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). In RATS, the Conceptional Messages defined can potentially be subscribed to. Specifically, the YANG module defined in this document augments the YANG module for TPM-based Challenge-Response based Remote Attestation (CHARRA) to allow for subscription to the Conceptual Message type Evidence. Additionally, this memo provides the methods and means to define additional Event Streams for other Conceptual Messages than Evidence as illustrated in the RATS Architecture, e.g., Attestation Results, Reference Values, or Endorsements. The module defined requires at least one TPM 1.2, TPM 2.0, or equivalent hardware implementation providing the same protected capabilities as TPMs to be available in the Attester the YANG server is running on. | |||||||||||||
| draft-ietf-rats-pkix-evidence-00.txt | ||||||||||||||
| PKI-based Attestation Evidence | ||||||||||||||
|
This document specifies ASN.1 structures produced by an Attester as part of the remote attestation procedures and constitute Evidence. This document follows the Remote ATtestation procedureS (RATS) architecture where Evidence is sent by an Attester and processed by a Verifier. | |||||||||||||
| draft-ietf-rats-posture-assessment-01.txt | ||||||||||||||
| Remote Posture Assessment for Systems,Containers,and Applications at Scale | ||||||||||||||
|
This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. | |||||||||||||
| draft-ietf-rats-reference-interaction-models-11.txt | ||||||||||||||
| Reference Interaction Models for Remote Attestation Procedures | ||||||||||||||
|
This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. | |||||||||||||
| draft-ietf-rats-uccs-12.txt | ||||||||||||||
| A CBOR Tag for Unprotected CWT Claims Sets | ||||||||||||||
|
This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, message authentication code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and processing considerations, and discusses security implications of using unprotected claims sets. // (This editors' note will be removed by the RFC editor:) The // present revision (–12) contains remaining document changes based // on feedback from the IESG evaluation and has been submitted as // input to IETF 121. | |||||||||||||
| draft-ietf-raw-architecture-22.txt | ||||||||||||||
| Reliable and Available Wireless Architecture | ||||||||||||||
|
Reliable and Available Wireless (RAW) improves the reliability and availability in DetNet networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, in particular intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected connectivity services. The loop involves a new Point of Local Repair function in the DetNet service sublayer that dynamically selects the DetNet path(s) for the future packets to route around local connectivity degradation. | |||||||||||||
| draft-ietf-raw-technologies-13.txt | ||||||||||||||
| Reliable and Available Wireless Technologies | ||||||||||||||
|
This document browses the short and middle range radio technologies that are suitable to provide a DetNet/RAW service over, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of its time of publication. The studied technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). Those technologies were selected as part of the WG formation and listed in the WG charter. | |||||||||||||
| draft-ietf-regext-epp-delete-bcp-09.txt | ||||||||||||||
| Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency. | |||||||||||||
| draft-ietf-regext-epp-eai-23.txt | ||||||||||||||
| Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
The Extensible Provisioning Protocol (EPP) does not natively support internationalized email addresses because the specifications for these addresses did not exist when EPP was developed. This document describes a command-response extension that adds support for associating either an internationalized email address or a second all-ASCII address with an EPP contact object and specifies how these addresses can be used by EPP clients and servers. | |||||||||||||
| draft-ietf-regext-epp-ttl-17.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values | ||||||||||||||
|
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. 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/epp-ttl-extension. | |||||||||||||
| draft-ietf-regext-rdap-extensions-04.txt | ||||||||||||||
| RDAP Extensions | ||||||||||||||
|
This document describes and clarifies the usage of extensions in RDAP. | |||||||||||||
| draft-ietf-regext-rdap-geofeed-08.txt | ||||||||||||||
| An RDAP Extension for Geofeed Data | ||||||||||||||
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and link relation type for the associated link objects included in responses. | |||||||||||||
| draft-ietf-regext-rdap-jscontact-19.txt | ||||||||||||||
| Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses | ||||||||||||||
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. | |||||||||||||
| draft-ietf-regext-rdap-rir-search-13.txt | ||||||||||||||
| RDAP RIR Search | ||||||||||||||
|
The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various IP and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. | |||||||||||||
| draft-ietf-regext-rdap-versioning-02.txt | ||||||||||||||
| Versioning in the Registration Data Access Protocol (RDAP) | ||||||||||||||
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. | |||||||||||||
| draft-ietf-regext-rdap-x-media-type-02.txt | ||||||||||||||
| An RDAP With Extensions Media Type | ||||||||||||||
|
This document defines a media type for RDAP that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this media type with RDAP for the purposes of signalling RDAP extensions during content negotiation. | |||||||||||||
| draft-ietf-rift-applicability-17.txt | ||||||||||||||
| RIFT Applicability and Operational Considerations | ||||||||||||||
|
This document discusses the properties, applicability and operational considerations of RIFT in different network scenarios. It intends to provide a rough guide how RIFT can be deployed to simplify routing operations in Clos topologies and their variations. | |||||||||||||
| draft-ietf-rift-auto-evpn-06.txt | ||||||||||||||
| RIFT Auto-EVPN | ||||||||||||||
|
This document specifies procedures that allow an EVPN overlay to be fully and automatically provisioned when using RIFT as underlay by leveraging RIFT's no-touch ZTP architecture. | |||||||||||||
| draft-ietf-rift-kv-tie-structure-and-processing-01.txt | ||||||||||||||
| RIFT Key/Value TIE Structure and Processing | ||||||||||||||
|
The RIFT (Routing in Fat-Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV- TIEs). The data contained within these KV-TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. | |||||||||||||
| draft-ietf-rift-rift-24.txt | ||||||||||||||
| RIFT: Routing in Fat Trees | ||||||||||||||
|
This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects, and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well. The protocol specified by this document is optimized toward the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for simplified deployment of said topologies. | |||||||||||||
| draft-ietf-rift-sr-01.txt | ||||||||||||||
| SRIFT: Segment Routing in Fat Trees | ||||||||||||||
|
This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic. | |||||||||||||
| draft-ietf-rift-yang-17.txt | ||||||||||||||
| YANG Data Model for Routing in Fat Trees (RIFT) | ||||||||||||||
|
This document defines a YANG data model for the configuration and management of Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC8342. | |||||||||||||
| draft-ietf-roll-aodv-rpl-19.txt | ||||||||||||||
| Supporting Asymmetric Links in Low Power Networks: AODV-RPL | ||||||||||||||
|
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. | |||||||||||||
| draft-ietf-roll-dao-projection-34.txt | ||||||||||||||
| Root initiated routing state in RPL | ||||||||||||||
|
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include itself, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. | |||||||||||||
| draft-ietf-roll-rnfd-04.txt | ||||||||||||||
| RNFD: Fast border router crash detection in RPL | ||||||||||||||
|
By and large, a correct operation of a RPL network requires border routers to be up. In many applications, it is beneficial for the nodes to detect a crash of a border router as soon as possible to trigger fallback actions. This document describes RNFD, an extension to RPL that expedites border router failure detection, even by an order of magnitude, by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Options for synchronizing this state among different nodes, and the coordination algorithm itself. | |||||||||||||
| draft-ietf-rtgwg-arp-yang-model-04.txt | ||||||||||||||
| A YANG Data Model for ARP | ||||||||||||||
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. | |||||||||||||
| draft-ietf-rtgwg-atn-bgp-27.txt | ||||||||||||||
| A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network | ||||||||||||||
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on industry-standard BGP to address the ATN/IPS requirements. | |||||||||||||
| draft-ietf-rtgwg-bgp-pic-21.txt | ||||||||||||||
| BGP Prefix Independent Convergence | ||||||||||||||
|
In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. | |||||||||||||
| draft-ietf-rtgwg-dst-src-routing-revive-02.txt | ||||||||||||||
| Destination/Source Routing | ||||||||||||||
|
This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously. | |||||||||||||
| draft-ietf-rtgwg-multisegment-sdwan-01.txt | ||||||||||||||
| Multi-segment SD-WAN via Cloud DCs | ||||||||||||||
|
This document describes a method for SD-WAN CPEs using GENEVE Encapsulation (RFC8926) to encapsulate the IPsec encrypted packets and send them to their closest Cloud GWs, who can steer the IPsec encrypted payload through the Cloud Backbone without decryption to the egress Cloud GWs which then forward the original IPsec encrypted payload to the destination CPEs. This method is for Cloud Backbone to connect multiple segments of SD-WAN without the Cloud GWs decrypting and re- encrypting the payloads. | |||||||||||||
| draft-ietf-rtgwg-net2cloud-problem-statement-41.txt | ||||||||||||||
| Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices | ||||||||||||||
|
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. | |||||||||||||
| draft-ietf-rtgwg-segment-routing-ti-lfa-19.txt | ||||||||||||||
| Topology Independent Fast Reroute using Segment Routing | ||||||||||||||
|
This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. | |||||||||||||
| draft-ietf-rtgwg-srv6-egress-protection-17.txt | ||||||||||||||
| SRv6 Path Egress Protection | ||||||||||||||
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. | |||||||||||||
| draft-ietf-rtgwg-vrrp-p2mp-bfd-10.txt | ||||||||||||||
| Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568. | |||||||||||||
| draft-ietf-rtgwg-vrrp-rfc8347bis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-satp-architecture-06.txt | ||||||||||||||
| Secure Asset Transfer (SAT) Interoperability Architecture | ||||||||||||||
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. | |||||||||||||
| draft-ietf-satp-core-07.txt | ||||||||||||||
| Secure Asset Transfer Protocol (SATP) Core | ||||||||||||||
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. | |||||||||||||
| draft-ietf-satp-usecases-04.txt | ||||||||||||||
| Secure Asset Transfer (SAT) Use Cases | ||||||||||||||
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. | |||||||||||||
| draft-ietf-savnet-inter-domain-architecture-00.txt | ||||||||||||||
| Inter-domain Source Address Validation (SAVNET) Architecture | ||||||||||||||
|
This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. | |||||||||||||
| draft-ietf-savnet-inter-domain-problem-statement-06.txt | ||||||||||||||
| Source Address Validation in Inter-domain Networks Gap Analysis,Problem Statement,and Requirements | ||||||||||||||
|
This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. | |||||||||||||
| draft-ietf-savnet-intra-domain-architecture-01.txt | ||||||||||||||
| Intra-domain Source Address Validation (SAVNET) Architecture | ||||||||||||||
|
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way. | |||||||||||||
| draft-ietf-savnet-intra-domain-problem-statement-08.txt | ||||||||||||||
| Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements | ||||||||||||||
|
This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. | |||||||||||||
| draft-ietf-schc-8824-update-03.txt | ||||||||||||||
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. | |||||||||||||
| draft-ietf-schc-icmpv6-compression-01.txt | ||||||||||||||
| Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6) | ||||||||||||||
|
This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages. | |||||||||||||
| draft-ietf-schc-over-networks-prone-to-disruptions-00.txt | ||||||||||||||
| Static Context Header Compression and Fragmentation over networks prone to disruptions | ||||||||||||||
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. | |||||||||||||
| draft-ietf-schc-protocol-numbers-00.txt | ||||||||||||||
| Protocol Numbers for SCHC | ||||||||||||||
|
This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. | |||||||||||||
| draft-ietf-scim-cursor-pagination-05.txt | ||||||||||||||
| Cursor-based Pagination of SCIM Resources | ||||||||||||||
|
This document defines additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM implementations that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. | |||||||||||||
| draft-ietf-scim-device-model-10.txt | ||||||||||||||
| Device Schema Extensions to the SCIM model | ||||||||||||||
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. | |||||||||||||
| draft-ietf-scim-events-07.txt | ||||||||||||||
| SCIM Profile for Security Event Tokens | ||||||||||||||
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. | |||||||||||||
| draft-ietf-scitt-architecture-10.txt | ||||||||||||||
| An Architecture for Trustworthy and Transparent Digital Supply Chains | ||||||||||||||
|
Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on any Transparency Service, with the guarantee that any Relying Parties will be able to verify them. | |||||||||||||
| draft-ietf-scitt-scrapi-02.txt | ||||||||||||||
| SCITT Reference APIs | ||||||||||||||
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability issues with Decentralized Identifiers, X509 Certificates and Artifact Repositories. | |||||||||||||
| draft-ietf-sfc-nsh-ecn-support-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-sidrops-8210bis-16.txt | ||||||||||||||
| The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 | ||||||||||||||
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data and Router Keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. | |||||||||||||
| draft-ietf-sidrops-aspa-notation-02.txt | ||||||||||||||
| Human Readable ASPA Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). | |||||||||||||
| draft-ietf-sidrops-aspa-profile-18.txt | ||||||||||||||
| A Profile for Autonomous System Provider Authorization | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. | |||||||||||||
| draft-ietf-sidrops-aspa-slurm-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-sidrops-aspa-verification-19.txt | ||||||||||||||
| BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects | ||||||||||||||
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This type of AS_PATH verification provides detection and mitigation of route leaks and some forms of AS path manipulation. It also provides protection, to some degree, against prefix hijacks with forged-origin or forged- path-segment. | |||||||||||||
| draft-ietf-sidrops-avoid-rpki-state-in-bgp-01.txt | ||||||||||||||
| Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes | ||||||||||||||
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with transitive attributes signaling Validation State may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators SHOULD ensure Validation States are not signaled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into BGP Communities. | |||||||||||||
| draft-ietf-sidrops-bar-sav-05.txt | ||||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | ||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | |||||||||||||
| draft-ietf-sidrops-manifest-numbers-02.txt | ||||||||||||||
| RPKI Manifest Number Handling | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. | |||||||||||||
| draft-ietf-sidrops-moa-profile-00.txt | ||||||||||||||
| A Profile for Mapping Origin Authorizations (MOAs) | ||||||||||||||
|
This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object, it provides a means that the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. When receiving the MOA objects from the relying partie, PE device can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. | |||||||||||||
| draft-ietf-sidrops-publication-server-bcp-01.txt | ||||||||||||||
| RPKI Publication Server Best Current Practices | ||||||||||||||
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. | |||||||||||||
| draft-ietf-sidrops-rpki-crl-numbers-00.txt | ||||||||||||||
| Relying Party Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions | ||||||||||||||
|
This document clarifies how Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) handle Certificate Revocation List (CRL) Number extensions. This document updates RFC 6487. | |||||||||||||
| draft-ietf-sidrops-rpki-prefixlist-04.txt | ||||||||||||||
| A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by the subject AS. | |||||||||||||
| draft-ietf-sidrops-rpki-ta-tiebreaker-00.txt | ||||||||||||||
| Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors | ||||||||||||||
|
A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document proposes a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. | |||||||||||||
| draft-ietf-sidrops-rpki-validation-update-01.txt | ||||||||||||||
| Revision of the RPKI Validation Algorithm | ||||||||||||||
|
This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6487. This document updates RFC 9582. This document obsoletes RFC 8360. | |||||||||||||
| draft-ietf-sidrops-spl-verification-01.txt | ||||||||||||||
| Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations | ||||||||||||||
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. | |||||||||||||
| draft-ietf-sidrops-vrp-notation-02.txt | ||||||||||||||
| Human Readable Validate ROA Payload Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. | |||||||||||||
| draft-ietf-sipcore-callinfo-rcd-12.txt | ||||||||||||||
| SIP Call-Info Parameters for Rich Call Data | ||||||||||||||
|
This document describes a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the calling party in order to provide to the called party a description of the caller or details about the reason for the call. RCD includes information about the caller beyond the telephone number such as a calling name, or a logo, photo, or jCard object representing the caller, which can help the called party decide whether to answer the phone. The elements defined for this purpose are intended to be extensible in order to accommodate related information about calls and to be compatible and complimentary with the STIR/PASSporT RCD framework. This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon". | |||||||||||||
| draft-ietf-sipcore-rfc7976bis-00.txt | ||||||||||||||
| Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses | ||||||||||||||
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. | |||||||||||||
| draft-ietf-sml-structured-email-02.txt | ||||||||||||||
| Structured Email | ||||||||||||||
|
This document specifies how a machine-readable version of the content of email messages can be added to those messages. | |||||||||||||
| draft-ietf-sml-structured-email-use-cases-02.txt | ||||||||||||||
| Structured Email: Use cases | ||||||||||||||
|
This document collects and discusses use cases for "structured email" [I-D.ietf-sml-structured-email-02]. | |||||||||||||
| draft-ietf-snac-simple-06.txt | ||||||||||||||
| Automatically Connecting Stub Networks to Unmanaged Infrastructure | ||||||||||||||
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). | |||||||||||||
| draft-ietf-spice-sd-cwt-02.txt | ||||||||||||||
| SPICE SD-CWT | ||||||||||||||
|
This document describes a data minimization technique for use with CBOR Web Token (CWT). The approach is based on Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE). | |||||||||||||
| draft-ietf-spice-use-cases-00.txt | ||||||||||||||
| Use Cases for SPICE | ||||||||||||||
|
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation. | |||||||||||||
| draft-ietf-spring-bfd-12.txt | ||||||||||||||
| Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane | ||||||||||||||
|
Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without changing the data plane. Bidirectional Forwarding Detection (BFD) is expected to monitor a segment list, representing a specific source-routed SR Policy path between the headend and an endpoint. This document describes using BFD for monitoring individual segment lists of candidate paths of an SR Policy. It documents the use of various BFD modes and features such as BFD Demand mode, Seamless BFD, and BFD Echo function with the BFD Control packet payload in the SR-MPLS domain. Also, this document defines how to use Label Switched Path Ping to bootstrap a BFD session, with optional control of selecting a segment list in the reverse direction of the BFD session. | |||||||||||||
| draft-ietf-spring-cs-sr-policy-03.txt | ||||||||||||||
| Circuit Style Segment Routing Policies | ||||||||||||||
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). | |||||||||||||
| draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-05.txt | ||||||||||||||
| Distribute SRv6 Locator by DHCP | ||||||||||||||
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through DHCPv6. | |||||||||||||
| draft-ietf-spring-pmtu-sr-policy-01.txt | ||||||||||||||
| Path MTU (PMTU) for Segment Routing (SR) Policy | ||||||||||||||
|
This document defines the Path MTU (PMTU) for Segment Routing (SR) Policy (called SR-PMTU). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU for SR Policy including the link MTU collection, the SR-PMTU computation, the SR-PMTU enforcement, and the handling behaviours on the headend. | |||||||||||||
| draft-ietf-spring-resource-aware-segments-10.txt | ||||||||||||||
| Introducing Resource Awareness to SR Segments | ||||||||||||||
|
This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). | |||||||||||||
| draft-ietf-spring-segment-protection-sr-te-paths-07.txt | ||||||||||||||
| Segment Protection for SR-TE Paths | ||||||||||||||
|
Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. | |||||||||||||
| draft-ietf-spring-sr-for-enhanced-vpn-08.txt | ||||||||||||||
| Segment Routing based Network Resource Partition (NRP) for Enhanced VPN | ||||||||||||||
|
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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. | |||||||||||||
| draft-ietf-spring-sr-policy-yang-04.txt | ||||||||||||||
| YANG Data Model for Segment Routing Policy | ||||||||||||||
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. | |||||||||||||
| draft-ietf-spring-sr-service-programming-10.txt | ||||||||||||||
| Service Programming with Segment Routing | ||||||||||||||
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. | |||||||||||||
| draft-ietf-spring-srv6-mpls-interworking-00.txt | ||||||||||||||
| SRv6 and MPLS interworking | ||||||||||||||
|
This document describes SRv6 and MPLS/SR-MPLS interworking procedures. Interworking problem is generalized into various interworking scenarios. These scenarios are stitched either by transport interworking or service interworking. New SRv6 behaviors are defined for the purpose. These new behaviors and MPLS labels stitch end to end path across different data plane. | |||||||||||||
| draft-ietf-spring-srv6-path-segment-11.txt | ||||||||||||||
| Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6) | ||||||||||||||
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment Identifier (PSID) has been defined to identify an SR path in SR-MPLS networks, and is used for various use- cases such as end-to-end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the PSID to identify an SRv6 path in an IPv6 network. | |||||||||||||
| draft-ietf-spring-srv6-security-01.txt | ||||||||||||||
| Segment Routing IPv6 Security Considerations | ||||||||||||||
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. | |||||||||||||
| draft-ietf-spring-srv6-srh-compression-19.txt | ||||||||||||||
| Compressed SRv6 Segment List Encoding | ||||||||||||||
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 SID list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. | |||||||||||||
| draft-ietf-spring-srv6-yang-04.txt | ||||||||||||||
| YANG Data Model for SRv6 Base and Static | ||||||||||||||
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-spring-stamp-srpm-17.txt | ||||||||||||||
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks | ||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. | |||||||||||||
| draft-ietf-sshm-ntruprime-ssh-01.txt | ||||||||||||||
| Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 | ||||||||||||||
|
This document describe a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. | |||||||||||||
| draft-ietf-sshm-ssh-agent-01.txt | ||||||||||||||
| SSH Agent Protocol | ||||||||||||||
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. | |||||||||||||
| draft-ietf-stir-certificates-ocsp-08.txt | ||||||||||||||
| OCSP Usage for Secure Telephone Identity Certificates | ||||||||||||||
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. | |||||||||||||
| draft-ietf-stir-certificates-shortlived-02.txt | ||||||||||||||
| Short-Lived Certificates for Secure Telephone Identity | ||||||||||||||
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. | |||||||||||||
| draft-ietf-stir-passport-rcd-26.txt | ||||||||||||||
| PASSporT Extension for Rich Call Data | ||||||||||||||
|
This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. | |||||||||||||
| draft-ietf-stir-rfc4916-update-06.txt | ||||||||||||||
| Connected Identity for STIR | ||||||||||||||
|
The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. | |||||||||||||
| draft-ietf-stir-servprovider-oob-06.txt | ||||||||||||||
| Out-of-Band STIR for Service Providers | ||||||||||||||
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a Session Initiation Protocl (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. | |||||||||||||
| draft-ietf-suit-firmware-encryption-22.txt | ||||||||||||||
| Encrypted Payloads in SUIT Manifests | ||||||||||||||
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. | |||||||||||||
| draft-ietf-suit-manifest-32.txt | ||||||||||||||
| A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest | ||||||||||||||
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. | |||||||||||||
| draft-ietf-suit-mti-08.txt | ||||||||||||||
| Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests | ||||||||||||||
|
This document specifies algorithm profiles for SUIT manifest parsers and authors to ensure better interoperability. These profiles apply specifically to a constrained node software update use case. | |||||||||||||
| draft-ietf-suit-mud-09.txt | ||||||||||||||
| Strong Assertions of IoT Network Access Requirements | ||||||||||||||
|
The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two. | |||||||||||||
| draft-ietf-suit-report-10.txt | ||||||||||||||
| Secure Reporting of Update Status | ||||||||||||||
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. | |||||||||||||
| draft-ietf-suit-trust-domains-09.txt | ||||||||||||||
| SUIT Manifest Extensions for Multiple Trust Domains | ||||||||||||||
|
This specification describes extensions to the SUIT Manifest format for use in deployments with multiple trust domains. A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. | |||||||||||||
| draft-ietf-suit-update-management-07.txt | ||||||||||||||
| Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests | ||||||||||||||
|
This specification describes extensions to the SUIT manifest format defined in [I-D.ietf-suit-manifest]. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. | |||||||||||||
| draft-ietf-taps-arch-19.txt | ||||||||||||||
| Architecture and Requirements for Transport Services | ||||||||||||||
|
This document describes an architecture for exposing transport protocol features to applications for network communication. This system exposes transport protocol features to applications for network communication. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. This API uses messages for representing data transfer to applications, and describes how a Transport Services Implementation can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document provides the architecture and requirements. It defines common terminology and concepts to be used in definitions of a Transport Service API and a Transport Services Implementation. | |||||||||||||
| draft-ietf-taps-impl-18.txt | ||||||||||||||
| Implementing Interfaces to Transport Services | ||||||||||||||
|
The Transport Services system enables applications to use transport protocols flexibly for network communication and defines a protocol- independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementing such a system. | |||||||||||||
| draft-ietf-taps-interface-26.txt | ||||||||||||||
| An Abstract Application Layer Interface to Transport Services | ||||||||||||||
|
This document describes an abstract application programming interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services architecture by providing asynchronous, atomic transmission of messages. It is intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols. | |||||||||||||
| draft-ietf-tcpm-accurate-ecn-30.txt | ||||||||||||||
| More Accurate Explicit Congestion Notification (ECN) Feedback in TCP | ||||||||||||||
|
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is exploited to feed back the IP-ECN field received during the 3-way handshake as well. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes. | |||||||||||||
| draft-ietf-tcpm-ack-rate-request-06.txt | ||||||||||||||
| TCP ACK Rate Request Option | ||||||||||||||
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. | |||||||||||||
| draft-ietf-tcpm-generalized-ecn-16.txt | ||||||||||||||
| ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets | ||||||||||||||
|
This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone. | |||||||||||||
| draft-ietf-tcpm-prr-rfc6937bis-13.txt | ||||||||||||||
| Proportional Rate Reduction for TCP | ||||||||||||||
|
This document updates the experimental Proportional Rate Reduction (PRR) algorithm, described RFC 6937, to standards track. PRR provides logic to regulate the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm. | |||||||||||||
| draft-ietf-tcpm-tcp-edo-14.txt | ||||||||||||||
| TCP Extended Data Offset Option | ||||||||||||||
|
TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 9293 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. | |||||||||||||
| draft-ietf-tcpm-tcp-ghost-acks-01.txt | ||||||||||||||
| Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs | ||||||||||||||
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. | |||||||||||||
| draft-ietf-teas-5g-ns-ip-mpls-13.txt | ||||||||||||||
| A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies | ||||||||||||||
|
Slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks. | |||||||||||||
| draft-ietf-teas-actn-pm-telemetry-autonomics-14.txt | ||||||||||||||
| YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics | ||||||||||||||
|
This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. | |||||||||||||
| draft-ietf-teas-actn-poi-applicability-12.txt | ||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) | ||||||||||||||
|
This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-technology (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. | |||||||||||||
| draft-ietf-teas-actn-vn-yang-29.txt | ||||||||||||||
| A YANG Data Model for Virtual Network (VN) Operations | ||||||||||||||
|
A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it was a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework. | |||||||||||||
| draft-ietf-teas-applicability-actn-slicing-10.txt | ||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing | ||||||||||||||
|
Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. | |||||||||||||
| draft-ietf-teas-enhanced-vpn-20.txt | ||||||||||||||
| A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks | ||||||||||||||
|
This document describes the framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). An NRP represents a subset of network resources and associated policies in the underlay network. NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work. | |||||||||||||
| draft-ietf-teas-gmpls-controller-inter-work-17.txt | ||||||||||||||
| Interworking of GMPLS Control and Centralized Controller Systems | ||||||||||||||
|
Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453. Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than competing. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network. | |||||||||||||
| draft-ietf-teas-ietf-network-slice-nbi-yang-17.txt | ||||||||||||||
| A YANG Data Model for the RFC 9543 Network Slice Service | ||||||||||||||
|
This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. | |||||||||||||
| draft-ietf-teas-nrp-scalability-06.txt | ||||||||||||||
| Scalability Considerations for Network Resource Partition | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. | |||||||||||||
| draft-ietf-teas-nrp-yang-02.txt | ||||||||||||||
| YANG Data Models for Network Resource Partitions (NRPs) | ||||||||||||||
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. | |||||||||||||
| draft-ietf-teas-ns-controller-models-03.txt | ||||||||||||||
| IETF Network Slice Controller and its Associated Data Models | ||||||||||||||
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. | |||||||||||||
| draft-ietf-teas-rfc8776-update-14.txt | ||||||||||||||
| Common YANG Data Types for Traffic Engineering | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. | |||||||||||||
| draft-ietf-teas-sf-aware-topo-model-13.txt | ||||||||||||||
| SF Aware TE Topology YANG Model | ||||||||||||||
|
This document describes a YANG data model for TE network topologies that are network service and function aware. | |||||||||||||
| draft-ietf-teas-te-service-mapping-yang-16.txt | ||||||||||||||
| Traffic Engineering (TE) and Service Mapping YANG Data Model | ||||||||||||||
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. | |||||||||||||
| draft-ietf-teas-te-topology-profiles-02.txt | ||||||||||||||
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases | ||||||||||||||
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". | |||||||||||||
| draft-ietf-teas-yang-l3-te-topo-18.txt | ||||||||||||||
| YANG Data Model for Layer 3 TE Topologies | ||||||||||||||
|
This document defines a YANG data model for layer 3 traffic engineering topologies. | |||||||||||||
| draft-ietf-teas-yang-path-computation-23.txt | ||||||||||||||
| A YANG Data Model for requesting path computation | ||||||||||||||
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. | |||||||||||||
| draft-ietf-teas-yang-sr-te-topo-19.txt | ||||||||||||||
| YANG Data Model for SR and SR TE Topologies on MPLS Data Plane | ||||||||||||||
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) traffic engineering (TE) topology, using MPLS data plane. | |||||||||||||
| draft-ietf-teas-yang-te-37.txt | ||||||||||||||
| A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths and Interfaces | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. | |||||||||||||
| draft-ietf-teas-yang-te-mpls-topology-01.txt | ||||||||||||||
| A YANG Data Model for MPLS-TE Topology | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. | |||||||||||||
| draft-ietf-teas-yang-topology-filter-00.txt | ||||||||||||||
| YANG Data Model for Topology Filter | ||||||||||||||
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. | |||||||||||||
| draft-ietf-teep-otrp-over-http-15.txt | ||||||||||||||
| HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication | ||||||||||||||
|
The Trusted Execution Environment Provisioning (TEEP) Protocol is used to manage code and configuration data in a Trusted Execution Environment (TEE). This document specifies the HTTP transport for TEEP communication where a Trusted Application Manager (TAM) service is used to manage code and data in TEEs on devices that can initiate communication to the TAM. | |||||||||||||
| draft-ietf-teep-protocol-20.txt | ||||||||||||||
| Trusted Execution Environment Provisioning (TEEP) Protocol | ||||||||||||||
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. | |||||||||||||
| draft-ietf-teep-usecase-for-cc-in-network-08.txt | ||||||||||||||
| TEEP Usecase for Confidential Computing in Network | ||||||||||||||
|
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC and other scenarios to use confidential computing in network. | |||||||||||||
| draft-ietf-tictoc-ptp-enterprise-profile-28.txt | ||||||||||||||
| Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages | ||||||||||||||
|
This document describes a Precision Time Protocol (PTP) Profile IEEE 1588-2019 [IEEE1588] for use in an IPv4 or IPv6 Enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allows both multicast and unicast Delay Request and Delay Response messages. | |||||||||||||
| draft-ietf-tls-8773bis-02.txt | ||||||||||||||
| TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key | ||||||||||||||
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with a combination of a certificate and an external pre-shared key (PSK). | |||||||||||||
| draft-ietf-tls-cert-abridge-02.txt | ||||||||||||||
| Abridged Compression for WebPKI Certificates | ||||||||||||||
|
This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. | |||||||||||||
| draft-ietf-tls-deprecate-obsolete-kex-05.txt | ||||||||||||||
| Deprecating Obsolete Key Exchange Methods in TLS 1.2 | ||||||||||||||
|
This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. | |||||||||||||
| draft-ietf-tls-dtls-rrc-12.txt | ||||||||||||||
| Return Routability Check for DTLS 1.2 and DTLS 1.3 | ||||||||||||||
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. | |||||||||||||
| draft-ietf-tls-ech-keylogfile-01.txt | ||||||||||||||
| SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH) | ||||||||||||||
|
This document specifies an extension to the SSLKEYLOGFILE format to support the logging of information about Encrypted Client Hello (ECH) related secrets. Two new labels are introduced, namely ECH_SECRET and ECH_CONFIG, which log the Hybrid Public Key Encryption (HPKE)- derived shared secret and the ECHConfig used for the ECH, respectively. This extension aims to facilitate debugging of TLS connections employing ECH. | |||||||||||||
| draft-ietf-tls-esni-22.txt | ||||||||||||||
| TLS Encrypted Client Hello | ||||||||||||||
|
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. 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/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). | |||||||||||||
| draft-ietf-tls-extended-key-update-03.txt | ||||||||||||||
| Extended Key Update for Transport Layer Security (TLS) 1.3 | ||||||||||||||
|
The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. | |||||||||||||
| draft-ietf-tls-hybrid-design-11.txt | ||||||||||||||
| Hybrid key exchange in TLS 1.3 | ||||||||||||||
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. | |||||||||||||
| draft-ietf-tls-key-share-prediction-01.txt | ||||||||||||||
| TLS Key Share Prediction | ||||||||||||||
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. | |||||||||||||
| draft-ietf-tls-rfc8446bis-11.txt | ||||||||||||||
| The Transport Layer Security (TLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. | |||||||||||||
| draft-ietf-tls-rfc8447bis-10.txt | ||||||||||||||
| IANA Registry Updates for TLS and DTLS | ||||||||||||||
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries and adds a "Comments" column to all active registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. | |||||||||||||
| draft-ietf-tls-rfc9147bis-00.txt | ||||||||||||||
| The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. | |||||||||||||
| draft-ietf-tls-super-jumbo-record-limit-00.txt | ||||||||||||||
| Large Record Sizes for TLS and DTLS with Reduced Overhead | ||||||||||||||
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead. | |||||||||||||
| draft-ietf-tls-svcb-ech-06.txt | ||||||||||||||
| Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | ||||||||||||||
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. | |||||||||||||
| draft-ietf-tls-tls12-frozen-05.txt | ||||||||||||||
| TLS 1.2 is in Feature Freeze | ||||||||||||||
|
Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. | |||||||||||||
| draft-ietf-tls-tls13-pkcs1-02.txt | ||||||||||||||
| Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 | ||||||||||||||
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. | |||||||||||||
| draft-ietf-tls-tlsflags-14.txt | ||||||||||||||
| A Flags Extension for TLS 1.3 | ||||||||||||||
|
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. | |||||||||||||
| draft-ietf-tls-wkech-06.txt | ||||||||||||||
| A well-known URI for publishing service parameters | ||||||||||||||
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too. | |||||||||||||
| draft-ietf-tsvwg-careful-resume-12.txt | ||||||||||||||
| Convergence of Congestion Control from Retained State | ||||||||||||||
|
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections. It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the congestion control behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of Careful Resume impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. | |||||||||||||
| draft-ietf-tsvwg-multipath-dccp-17.txt | ||||||||||||||
| DCCP Extensions for Multipath Operation with Multiple Addresses | ||||||||||||||
|
DCCP communications as defined in RFC 4340 are restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of available multiple paths for a DCCP session could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failures. Use cases for Multipath DCCP (MP-DCCP) are mobile devices (e.g., handsets, vehicles) and residential home gateways simultaneously connected to distinct networks as, e.g., a cellular and a Wireless Local Area (WLAN) network or a cellular and a fixed access network. Compared to existing multipath protocols such as MPTCP, MP-DCCP offers special support for latency-sensitive services with different requirements for reliability and in-order delivery. This document specifies a set of extensions to DCCP to support multipath operations. The protocol offers the same type of service to applications as DCCP and provides the components necessary to establish and use multiple DCCP flows across different paths simultaneously. | |||||||||||||
| draft-ietf-tsvwg-nqb-27.txt | ||||||||||||||
| A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services | ||||||||||||||
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] | |||||||||||||
| draft-ietf-tsvwg-rfc4895-bis-04.txt | ||||||||||||||
| Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) | ||||||||||||||
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895. | |||||||||||||
| draft-ietf-tsvwg-udp-ecn-00.txt | ||||||||||||||
| Configuring UDP Sockets for ECN for Common Platforms | ||||||||||||||
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. | |||||||||||||
| draft-ietf-tsvwg-udp-options-38.txt | ||||||||||||||
| Transport Options for UDP | ||||||||||||||
|
Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP length. | |||||||||||||
| draft-ietf-tsvwg-udp-options-dplpmtud-13.txt | ||||||||||||||
| Datagram PLPMTUD for UDP Options | ||||||||||||||
|
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required. | |||||||||||||
| draft-ietf-tsvwg-usr-exp-02.txt | ||||||||||||||
| User Ports for Experiments | ||||||||||||||
|
This document defines user ports for experiments using transport protocols. It describes the use of experiment identifiers to enable shared use of these user ports, as well as updating the use of system ports for experiments in the same manner. | |||||||||||||
| draft-ietf-tvr-requirements-04.txt | ||||||||||||||
| TVR (Time-Variant Routing) Requirements | ||||||||||||||
|
Time-Variant Routing (TVR) refers to calculating a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route This document introduces requirements where TVR computations could improve message exchange in a network. | |||||||||||||
| draft-ietf-tvr-schedule-yang-03.txt | ||||||||||||||
| YANG Data Model for Scheduled Attributes | ||||||||||||||
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. | |||||||||||||
| draft-ietf-uta-require-tls13-03.txt | ||||||||||||||
| New Protocols Must Require TLS 1.3 | ||||||||||||||
|
TLS 1.2 is in use and can be configured such that it provides good security properties. TLS 1.3 use is increasing, and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. For these reasons, new protocols must require and assume the existence of TLS 1.3 existence. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. This document updates [RFC9325]. | |||||||||||||
| draft-ietf-uta-tls13-iot-profile-11.txt | ||||||||||||||
| TLS/DTLS 1.3 Profiles for the Internet of Things | ||||||||||||||
|
This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile and ciphersuite requirements. | |||||||||||||
| draft-ietf-v6ops-6mops-00.txt | ||||||||||||||
| IPv6-Mostly Networks: Deployment and Operations Considerations | ||||||||||||||
|
This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). | |||||||||||||
| draft-ietf-v6ops-claton-02.txt | ||||||||||||||
| 464XLAT Customer-side Translator (CLAT): Node Recommendations | ||||||||||||||
|
464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions. | |||||||||||||
| draft-ietf-v6ops-cpe-lan-pd-05.txt | ||||||||||||||
| IPv6 CE Routers LAN Prefix Delegation | ||||||||||||||
|
This document defines requirements for IPv6 CE Routers to support DHCPv6 Prefix Delegation for redistributing any unused prefix(es) that were delegated to the IPv6 CE Router. This document updates RFC 7084. | |||||||||||||
| draft-ietf-v6ops-framework-md-ipv6only-underlay-08.txt | ||||||||||||||
| Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service | ||||||||||||||
|
For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 services(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in one multi- domain underlay network. It lists the requirements of service traffic, illustrates major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery from the perspective of network operation. The document also discusses related security considerations. | |||||||||||||
| draft-ietf-v6ops-nd-considerations-08.txt | ||||||||||||||
| Neighbor Discovery Considerations in IPv6 Deployments | ||||||||||||||
|
Neighbor Discovery (ND) is a critical part of IPv6. ND uses multicast extensively and trusts all hosts. In some scenarios, such as wireless networks, multicast can be inefficient. In other scenarios, such as public access networks, hosts may not be trustworthy. Consequently, ND can have issues in some scenarios. The issues and mitigation solutions are documented in more than 20 RFCs, making it challenging to track all these issues and solutions. Therefore, an overview document is helpful. This document first summarizes the published ND issues and the solutions. This provides a one-stop reference. This document then analyzes these mitigation solutions to reveal that isolating hosts into different subnets or links can help prevent ND issues. Three isolation methods and their applicability are described. A simple guideline is provided for selecting a suitable isolation method to prevent potential ND issues. | |||||||||||||
| draft-ietf-v6ops-rfc7084bis-01.txt | ||||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | ||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. | |||||||||||||
| draft-ietf-v6ops-ula-usage-considerations-05.txt | ||||||||||||||
| Considerations For Using Unique Local Addresses | ||||||||||||||
|
This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them. | |||||||||||||
| draft-ietf-vcon-vcon-container-01.txt | ||||||||||||||
| The JSON format for vCon - Conversation Data Container | ||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | |||||||||||||
| draft-ietf-webtrans-http2-10.txt | ||||||||||||||
| WebTransport over HTTP/2 | ||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | |||||||||||||
| draft-ietf-webtrans-http3-11.txt | ||||||||||||||
| WebTransport over HTTP/3 | ||||||||||||||
|
WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. | |||||||||||||
| draft-ietf-webtrans-overview-08.txt | ||||||||||||||
| The WebTransport Protocol Framework | ||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. | |||||||||||||
| draft-ietf-wimse-arch-02.txt | ||||||||||||||
| Workload Identity in a Multi System Environment (WIMSE) Architecture | ||||||||||||||
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. | |||||||||||||
| draft-ietf-wimse-s2s-protocol-01.txt | ||||||||||||||
| WIMSE Service to Service Authentication | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Service A can call Service B with mutual TLS authentication, while the next call from Service B to Service C would be authenticated at the application level. | |||||||||||||
| draft-ietf-wimse-workload-identity-practices-00.txt | ||||||||||||||
| Workload Identity Practices | ||||||||||||||
|
The use of the OAuth 2.0 framework in container orchestration systems poses challenges, particularly in managing credentials such as client_id and client_secret, which can be complex and prone to errors. To address this, the industry has shifted towards a federation-based approach where credentials of the underlying workload platform are used as assertions towards an OAuth authorization server, leveraging the Assertion Framework for OAuth 2.0 Client Authentication [RFC7521], specifically [RFC7523]. This specification describes a meta flow in Section 3.1, gives security recommendations in Section 4 and outlines concrete patterns in Appendix A. | |||||||||||||
| draft-ietf-wish-whep-02.txt | ||||||||||||||
| WebRTC-HTTP Egress Protocol (WHEP) | ||||||||||||||
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). | |||||||||||||
| draft-ietf-wish-whip-16.txt | ||||||||||||||
| WebRTC-HTTP ingestion protocol (WHIP) | ||||||||||||||
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This document updates RFC 8842 and RFC 8840. | |||||||||||||
| draft-ietf0-idr-srv6-flowspec-path-redirect-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ihlar-scone-masque-mediabitrate-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ihle-mpls-mna-stateless-egress-protection-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-illyes-rep-purpose-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-illyes-repext-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-interop-mimi-discovery-requirements-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-intesigroup-dlts-10.txt | ||||||||||||||
| Distributed Ledger Time-Stamp | ||||||||||||||
|
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. | |||||||||||||
| draft-iplir-protocol-06.txt | ||||||||||||||
| IPlir network layer security protocol | ||||||||||||||
|
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. | |||||||||||||
| draft-irtf-cfrg-aead-limits-09.txt | ||||||||||||||
| Usage Limits on AEAD Algorithms | ||||||||||||||
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. | |||||||||||||
| draft-irtf-cfrg-aead-properties-09.txt | ||||||||||||||
| Properties of AEAD Algorithms | ||||||||||||||
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group. | |||||||||||||
| draft-irtf-cfrg-aegis-aead-14.txt | ||||||||||||||
| The AEGIS Family of Authenticated Encryption Algorithms | ||||||||||||||
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. 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/cfrg/draft-irtf-cfrg-aegis-aead. | |||||||||||||
| draft-irtf-cfrg-bbs-signatures-07.txt | ||||||||||||||
| The BBS Signature Scheme | ||||||||||||||
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs-of-knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages. | |||||||||||||
| draft-irtf-cfrg-cpace-13.txt | ||||||||||||||
| CPace,a balanced composable PAKE | ||||||||||||||
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. | |||||||||||||
| draft-irtf-cfrg-det-sigs-with-noise-04.txt | ||||||||||||||
| Hedged ECDSA and EdDSA Signatures | ||||||||||||||
|
Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. | |||||||||||||
| draft-irtf-cfrg-dnhpke-05.txt | ||||||||||||||
| Deterministic Nonce-less Hybrid Public Key Encryption | ||||||||||||||
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. | |||||||||||||
| draft-irtf-cfrg-kangarootwelve-15.txt | ||||||||||||||
| KangarooTwelve and TurboSHAKE | ||||||||||||||
|
This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. | |||||||||||||
| draft-irtf-cfrg-opaque-18.txt | ||||||||||||||
| The OPAQUE Augmented PAKE Protocol | ||||||||||||||
|
This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | |||||||||||||
| draft-irtf-cfrg-partially-blind-rsa-00.txt | ||||||||||||||
| Partially Blind RSA Signatures | ||||||||||||||
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. | |||||||||||||
| draft-irtf-cfrg-rsa-guidance-01.txt | ||||||||||||||
| Implementation Guidance for the PKCS #1 RSA Cryptography Specification | ||||||||||||||
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. | |||||||||||||
| draft-irtf-cfrg-signature-key-blinding-07.txt | ||||||||||||||
| Key Blinding for Signature Schemes | ||||||||||||||
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. | |||||||||||||
| draft-irtf-cfrg-vdaf-13.txt | ||||||||||||||
| Verifiable Distributed Aggregation Functions | ||||||||||||||
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). | |||||||||||||
| draft-irtf-coinrg-use-case-analysis-02.txt | ||||||||||||||
| Use Case Analysis for Computing in the Network | ||||||||||||||
|
Computing in the Network (COIN) has the potential to enable a wide variety of use cases. The diversity in use cases makes challenges in defining general considerations. This document analyzes the use cases described in a COINRG companion document and potentially explores additional settings, to identify general aspects of interest across all use cases. The insights gained from this analysis will guide future COIN discussions. | |||||||||||||
| draft-irtf-coinrg-use-cases-07.txt | ||||||||||||||
| Use Cases for In-Network Computing | ||||||||||||||
|
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. It is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard. | |||||||||||||
| draft-irtf-hrpc-ipvc-01.txt | ||||||||||||||
| Intimate Partner Violence Digital Considerations | ||||||||||||||
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These security compromises go beyond active and passive on-path attacks [RFC7624]. With a focus on protocols, the document describes tactics of the IPV attacker and potential counter-measures. | |||||||||||||
| draft-irtf-iccrg-rledbat-09.txt | ||||||||||||||
| rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP | ||||||||||||||
|
This document specifies rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). | |||||||||||||
| draft-irtf-icnrg-flic-06.txt | ||||||||||||||
| File-Like ICN Collections (FLIC) | ||||||||||||||
|
This document describes a simple "index table" data structure and its associated Information Centric Networking (ICN) data objects for organizing a set of primitive ICN data objects into a large, File- Like ICN Collection (FLIC). At the core of this collection is a _manifest_ which acts as the collection's root node. The manifest contains an index table with pointers, each pointer being a hash value pointing to either a final data block or another index table node. | |||||||||||||
| draft-irtf-icnrg-reflexive-forwarding-00.txt | ||||||||||||||
| Reflexive Forwarding for CCNx and NDN Protocols | ||||||||||||||
|
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. | |||||||||||||
| draft-irtf-nmrg-ai-challenges-04.txt | ||||||||||||||
| Research Challenges in Coupling Artificial Intelligence and Network Management | ||||||||||||||
|
This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, there are many difficult problems in NM that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that network are operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| draft-irtf-nmrg-ai-deploy-00.txt | ||||||||||||||
| Considerations of network/system for AI services | ||||||||||||||
|
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. | |||||||||||||
| draft-irtf-nmrg-green-ps-03.txt | ||||||||||||||
| Challenges and Opportunities in Management for Green Networking | ||||||||||||||
|
Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they contribute to this footprint themselves in no insignificant way. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become "greener", i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| draft-irtf-nmrg-network-digital-twin-arch-08.txt | ||||||||||||||
| Network Digital Twin: Concepts and Reference Architecture | ||||||||||||||
|
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. | |||||||||||||
| draft-irtf-pearg-safe-internet-measurement-10.txt | ||||||||||||||
| Guidelines for Performing Safe Measurement on the Internet | ||||||||||||||
|
Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the internet, it can present risks to user privacy and safety. This document describes briefly those risks and proposes guidelines for ensuring that internet measurements can be carried out safely, with examples. | |||||||||||||
| draft-irtf-t2trg-amplification-attacks-04.txt | ||||||||||||||
| Amplification Attacks Using the Constrained Application Protocol (CoAP) | ||||||||||||||
|
Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. | |||||||||||||
| draft-irtf-t2trg-rest-iot-15.txt | ||||||||||||||
| Guidance on RESTful Design for Internet of Things Systems | ||||||||||||||
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). | |||||||||||||
| draft-irtf-t2trg-security-setup-iot-devices-03.txt | ||||||||||||||
| Terminology and processes for initial security setup of IoT devices | ||||||||||||||
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. | |||||||||||||
| draft-irtf-t2trg-taxonomy-manufacturer-anchors-04.txt | ||||||||||||||
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors | ||||||||||||||
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations | |||||||||||||
| draft-iuzh-ippm-ioam-integrity-yang-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jags-mpls-ps-mna-hdr-04.txt | ||||||||||||||
| Post-Stack MPLS Network Action (MNA) Solution | ||||||||||||||
|
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". | |||||||||||||
| draft-jaked-cared-00.txt | ||||||||||||||
| Client Authentication Recommendations for Encrypted DNS | ||||||||||||||
|
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. | |||||||||||||
| draft-james-privacy-primer-vcon-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jasdips-regext-rdap-rpki-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-jenkins-cnsa2-pkix-profile-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jenkins-emailpush-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jenkins-oauth-public-01.txt | ||||||||||||||
| OAuth Profile for Open Public Clients | ||||||||||||||
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. | |||||||||||||
| draft-jennings-moq-e2ee-mls-01.txt | ||||||||||||||
| Secure Group Key Agreement with MLS over MoQ | ||||||||||||||
|
This specification defines a mechanism to use Message Layer Security (MLS) to provide end-to-end group key agreement for Media over QUIC (MOQ) applications. Almost all communications are done via the MOQ transport. MLS requires a small degree of synchronization, which is provided by a simple counter service. | |||||||||||||
| draft-jennings-moq-file-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jennings-moq-log-00.txt | ||||||||||||||
| Logging over Media over QUIC Transport | ||||||||||||||
|
Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. | |||||||||||||
| draft-jennings-moq-metrics-00.txt | ||||||||||||||
| Metrics over MOQT | ||||||||||||||
|
Many systems produce significant volumes of metrics which either are not all needed at the same time for consumption by collection/ aggregation endpoints or will compete for bandwidth with the primary application, thus exacerbating congestion conditions especially in low-bandwidth networks. Delivering these over architectures enabled by publish/subscribe transport like Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport], allows metrics data to be prioritized within the congestion context of the primary application as well as enabling local nodes to cache the metric value to be later retrieved via new subscriptions. This document specifies how to send metrics type information over the Media Over QUIC Transport (MOQT). | |||||||||||||
| draft-jennings-moq-secure-objects-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jens-7050-secure-channel-00.txt | ||||||||||||||
| Redefining Secure Channel for ipv4only.arpa IPv6 Prefix Discovery | ||||||||||||||
|
This document updates [RFC7050] to redefine the term "secure channel" and modify requirements for nodes and DNS64 servers to use more recent developments in DNS security. | |||||||||||||
| draft-jeong-cats-its-use-cases-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jeong-i2nsf-security-management-automation-08.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-jeong-nmrg-ibn-network-management-automation-05.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-jeong-opsawg-i2inf-framework-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jeong-opsawg-i2inf-problem-statement-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jeong-opsawg-intent-based-sdv-framework-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jeong-opsawg-security-management-automation-00.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-jholland-quic-multicast-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ji-ccwg-distributed-lossless-mechanism-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jiang-bfd-multi-hop-unaffiliate-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jiang-cats-usecase-5gedge-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-jiang-idr-sr-policy-composite-path-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jiang-sidrops-psvro-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jiang-spring-parent-sr-policy-use-cases-04.txt | ||||||||||||||
| Use Cases for Parent 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 dynamic, explicit or composite. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment. | |||||||||||||
| draft-jiang-spring-sr-policy-nrp-01.txt | ||||||||||||||
| Segment Routing Policy Extension for NRP | ||||||||||||||
|
Network Resource Partition (NRP), which is a subset of the resources and associated policies in the underlay network. In networks with multiple NRPs, an SR Policy can be associated with a particular NRP. This document describes how the SR Policy extension for associated NRP and the operational mechanisms function together. | |||||||||||||
| draft-jiang-tsvwg-5gxrm-metadata-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jiang-tvr-sat-routing-consideration-01.txt | ||||||||||||||
| Routing Consideration for Satellite Constellation Network | ||||||||||||||
|
The 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on a satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves somewhat significant work to be explored in the IETF domain. This draft stems from the latest 3GPP satellite use cases, and lands on summarizing the restrictions & challenges in term of satellite-based routing. Based on some unique & advantageous characteristics associated with satellite movement, the draft raises briefly the general design principles and possible algorithms for the integrated NTN+TN routing, while leaves the implementation details for further expansion. | |||||||||||||
| draft-jimenez-tbd-robotstxt-update-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-johani-dnsop-delegation-mgmt-via-ddns-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-johansson-ccwg-rfc8298bis-screamv2-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-johnson-dns-ipn-cla-07.txt | ||||||||||||||
| DNS Resource Records for DTN Overlays | ||||||||||||||
|
Delay Tolerant Networks (DTNs) are typically characterized by high latency and lack of constant end to end connectivity, consistent with their use in deep space communications. This, however, is not the limit of application of Bundle Protocol (BP) and related DTN enabling technologies. Through a collection of Convergance Layer Adapters (CLAs), deployment overlaying the terrestrial Internet is a core component of DTN implementations. IPN is a integer based naming scheme for DTN networks. Notwithstanding cryptographic considerations, three basic components are necessary to enable a BP node to use the underlying Internet to communicate with another BP node: the IP address of the node, the CBHE Node Number (component of any ipn-scheme URI identifying a BP endpoint of which that node is a member), and the CLA which provides IP connectivity to that node. This document describes RRTYPE additions to DNS to enable terrestrial BP resource look-up. | |||||||||||||
| draft-johnson-dtn-interplanetary-dns-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-johnson-dtn-interplanetary-smtp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joras-scone-quic-protocol-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joras-scone-video-optimization-requirements-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joras-sconepro-quic-protocol-00.txt | ||||||||||||||
| 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 network properties between a content endpoint and an on-path device. This is achieved by sending messages in this new QUIC version format adjacent to already established QUIC version 1 or version 2 connections on the same UDP 4-tuple. The network properties are intended to enable self-adaptation of video media rates by content endpoints. | |||||||||||||
| draft-josefsson-chempat-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-josefsson-ssh-chacha20-poly1305-openssh-01.txt | ||||||||||||||
| Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305 | ||||||||||||||
|
This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. | |||||||||||||
| draft-joshco-symmetric-h2-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joshco-wpadng-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joung-detnet-asynch-detnet-framework-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-joung-detnet-stateless-fair-queuing-03.txt | ||||||||||||||
| Latency Guarantee with Stateless Fair Queuing | ||||||||||||||
|
This document specifies the framework and the operational procedure for deterministic networking with a set of work conserving packet schedulers that 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 a delay factor, which is a function of the flow and upstream 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, except the maximum packet length among other flows sharing each output link with the flow. | |||||||||||||
| draft-jouqui-netmod-yang-full-include-02.txt | ||||||||||||||
| YANG Full Embed | ||||||||||||||
|
YANG lacks re-usability of models defined outside of the grouping and augmentation mechanisms. For instance, it is almost impossible to reuse a model defined for a device in the context of the network, i.e by encapsulating it in a list indexed by device IDs. [RFC8528] defines the YANG mount mechanism, partially solving the problem by allowing to mount an arbitrary set of schemas at an arbitrary point. However, YANG mount is only focusing on deploy or runtime. This document aims to provide the same mechanism at design time. | |||||||||||||
| draft-kaippallimalil-tsvwg-media-hdr-wireless-05.txt | ||||||||||||||
| Media Handling Considerations for Wireless Networks | ||||||||||||||
|
Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Note: The solution in this draft will be revised to address requirements defined in [draft-kwbdgrr-tsvwg-net-collab-rqmts]. | |||||||||||||
| draft-kaliraj-bess-bgp-sig-private-mpls-labels-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kalos-bbs-blind-signatures-03.txt | ||||||||||||||
| Blind BBS Signatures | ||||||||||||||
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. 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/BasileiosKal/blind-bbs-signatures. | |||||||||||||
| draft-kalos-bbs-per-verifier-linkability-00.txt | ||||||||||||||
| BBS per Verifier Linkability | ||||||||||||||
|
The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. | |||||||||||||
| draft-kampanakis-curdle-ssh-pq-ke-05.txt | ||||||||||||||
| PQ/T Hybrid Key Exchange in SSH | ||||||||||||||
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on traditional ECDH key exchange and post- quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. | |||||||||||||
| draft-kampanakis-ml-kem-ikev2-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-karboubi-spring-sidlist-optimized-cs-sr-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-karcz-uuas-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-karstens-pim-multicast-application-ports-01.txt | ||||||||||||||
| The Multicast Application Ports | ||||||||||||||
|
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 two UDP ports specifically for use with multicast applications and lists requirements for using these ports. | |||||||||||||
| draft-kawakami-dmm-srv6-gtp6e-reduced-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kazuho-httpbis-incremental-http-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kb-capsule-conversion-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kcrh-hpwan-state-of-art-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kdj-nmrg-ibn-usecases-02.txt | ||||||||||||||
| Use Cases and Practices for Intent-Based Networking | ||||||||||||||
|
This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learning and general learning are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. | |||||||||||||
| draft-kdyxy-rats-tdx-eat-profile-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kerr-everybodys-shuffling-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kiefer-mls-light-01.txt | ||||||||||||||
| Light MLS | ||||||||||||||
|
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. | |||||||||||||
| draft-kiran-bess-service-carving-evpn-multi-homing-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-klassert-ipsecme-eesp-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-klassert-ipsecme-wespv2-01.txt | ||||||||||||||
| Wrapped ESP Version 2 | ||||||||||||||
|
This document describes the Wrapped Encapsulating Security Payload v2 (WESPv2) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303]. It is designed to overcome limitations of the ESP protocol to expose inner flow information to the network in a transparent way. To do so, it adapts IPv6 Extension header options to WESPv2 where flow identitiers can be stored. It also defines a Crypt Offset to allow intermediate devices to read some header bytes at the beginning of the inner packet. In particular, this preserves the original use-case of WESP [RFC5840]. | |||||||||||||
| draft-kleidl-digest-fields-problem-types-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-klensin-iana-consid-hybrid-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-klensin-idna-rfc5891bis-07.txt | ||||||||||||||
| Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations | ||||||||||||||
|
The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFCs 5890 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. | |||||||||||||
| draft-km-detnet-for-ocn-04.txt | ||||||||||||||
| Using Deterministic Networks for Industrial Operations and Control | ||||||||||||||
|
This document describes an application programming interface with a deterministic network domain. These APIs are used to select (or map) services in the Deterministic Network architecture. | |||||||||||||
| draft-knodel-beyond-carbon-00.txt | ||||||||||||||
| Impacts of the Internet on the Environment,Beyond Carbon | ||||||||||||||
|
The global internet is comprised of vast interconnected networks spanning nearly every surface of planet and sky that, together with user devices, consumes energy and emits greenhouse gases. The true scale and proposed mitigations of the carbon footprint of the internet are the subject of important research. The internet also requires the depletion of other natural resources beyond carbon, namely land, water, electromagnetic spectrum and minerals. Electronic waste contributes in particularly acute ways to environmental pollution. This document surveys the impacts of the internet on the environment and includes, but goes beyond, energy use and carbon footprint to look at the consumption of natural resources and environmental waste. | |||||||||||||
| draft-koch-librepgp-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-koch-openpgp-webkey-service-19.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kohbrok-mimi-metadata-minimalization-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kohbrok-mimi-portability-02.txt | ||||||||||||||
| MIMI Portability | ||||||||||||||
|
This document describes MIMI Portability mechanisms. | |||||||||||||
| draft-kohbrok-mls-associated-parties-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kohbrok-mls-virtual-clients-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kowalik-domainconnect-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kriswamy-idr-route-type-capability-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kucherawy-bcp97bis-05.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-kuehlewind-rswg-updates-tag-02.txt | ||||||||||||||
| Definition of new tags for relations between RFCs | ||||||||||||||
|
An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases. | |||||||||||||
| draft-kuehlewind-system-ports-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kunze-ark-40.txt | ||||||||||||||
| The ARK Identifier Scheme | ||||||||||||||
|
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]. | |||||||||||||
| draft-kwbdgrr-tsvwg-net-collab-rqmts-04.txt | ||||||||||||||
| Requirements for Host-to-Network Collaboration Signaling | ||||||||||||||
|
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). | |||||||||||||
| draft-kwiatkowski-tls-ecdhe-mlkem-02.txt | ||||||||||||||
| Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 | ||||||||||||||
|
This draft defines two hybrid key agreements for TLS 1.3: X25519MLKEM768 and SecP256r1MLKEM768, which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). | |||||||||||||
| draft-kwon-yoon-kim-ipake-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-laari-asdf-relations-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-labiod-rats-attester-groups-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lai-bmwg-istn-transport-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lai-ccwg-lsncc-00.txt | ||||||||||||||
| Analysis for the Adverse Effects of LEO Mobility on Internet Congestion Control | ||||||||||||||
|
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. | |||||||||||||
| draft-lamps-bonnell-keyusage-crl-validation-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lamps-okubo-certdiscovery-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lan-nvo3-qtp-20.txt | ||||||||||||||
| QoS-level aware Transmission Protocol (QTP) for virtual networks | ||||||||||||||
|
This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. | |||||||||||||
| draft-lan-sfp-establishment-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lanov-email-retention-period-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lanzhangwang-rtgwg-npmnrp-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-law-moq-warpstreamingformat-03.txt | ||||||||||||||
| WARP Streaming Format | ||||||||||||||
|
This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. | |||||||||||||
| draft-lbdd-cats-dp-sr-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lcmw-cats-midhaul-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lcurley-moq-transfork-02.txt | ||||||||||||||
| Media over QUIC - Transfork | ||||||||||||||
|
MoqTransfork is designed to serve a broadcast to an unbounded number of viewers with different 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. | |||||||||||||
| draft-lear-bcp83-replacement-00.txt | ||||||||||||||
| IETF Plenary List Management Procedures | ||||||||||||||
|
This memo provides a procedure and authority to address inappropriate behavior on IETF plenary lists. It obsoletes RFC 3683 and updates RFC 9245. | |||||||||||||
| draft-ledvina-apple-google-unwanted-trackers-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lee-asdf-digital-twin-04.txt | ||||||||||||||
| Extended information of 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. | |||||||||||||
| draft-lee-pce-pcep-ls-optical-14.txt | ||||||||||||||
| PCEP Extension for Distribution of Link-State and TE Information for Optical Networks | ||||||||||||||
|
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. | |||||||||||||
| draft-lehmann-idmefv2-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lehmann-idmefv2-https-transport-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lemieux-doi-uri-scheme-08.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-lemmons-cose-composite-claims-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lencse-bmwg-multiple-ip-addresses-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lenders-core-dnr-03.txt | ||||||||||||||
| Discovery of Network-designated OSCORE-based Resolvers: Problem Statement | ||||||||||||||
|
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. | |||||||||||||
| draft-lenders-dns-cbor-10.txt | ||||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | ||||||||||||||
|
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. | |||||||||||||
| draft-lennox-sdp-raw-key-fingerprints-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-levine-6man-repsize-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-levyabegnoli-bess-evpn-savi-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lh-spring-srv6-sfc-csid-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-6lo-pasa-reliability-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-arch-sat-09.txt | ||||||||||||||
| A Routing Architecture for Satellite Networks | ||||||||||||||
|
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms, enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. | |||||||||||||
| draft-li-coinrg-distributed-learning-architecture-03.txt | ||||||||||||||
| Distributed Learning Architecture based on Edge-cloud Collaboration | ||||||||||||||
|
This document describes the distributed learning architecture based on edge-cloud collaboration. | |||||||||||||
| draft-li-green-power-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-idr-bgpls-sr-policy-composite-path-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-idr-link-bandwidth-ext-02.txt | ||||||||||||||
| Extension of Link Bandwidth Extended Community | ||||||||||||||
|
[I-D.ietf-idr-link-bandwidth] defines a BGP link bandwidth extended community attribute, which can enable devices to implement unequal- cost load-balancing. However, the bandwidth value encapsulated by the extended community attribute is of the floating-point type, which is inconvenient to use. In this document, a set of new types of link bandwidth extended community are introduced to facilitate the configuration and calculation of link bandwidth. | |||||||||||||
| draft-li-istn-addressing-requirement-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-lsr-igp-based-intra-domain-savnet-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-lsr-igp-reverse-prefix-metric-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-lsr-ospf-purge-originator-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-lsvr-bgp-spf-sr-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-mpls-enhanced-vpn-vtn-id-04.txt | ||||||||||||||
| Carrying NRP Identifier and related information in MPLS Packet | ||||||||||||||
|
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 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 data plane NRP ID in an MPLS packet to identify the NRP the packet belongs to. The procedure for processing the data plane NRP ID is also specified. | |||||||||||||
| draft-li-mpls-mna-entropy-03.txt | ||||||||||||||
| 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". | |||||||||||||
| draft-li-mpls-mna-nrp-selector-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-nmrg-dtn-data-generation-optimization-02.txt | ||||||||||||||
| Data Generation and Optimization for Digital Twin Network Performance Modeling | ||||||||||||||
|
Digital Twin Network (DTN) can be used as a secure and cost-effective environment for network operators to evaluate network performance in various what-if scenarios. Recently, AI models, especially neural networks, have been applied for DTN performance modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model from the data perspective. | |||||||||||||
| draft-li-ppm-homomorphic-encryption-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-rtgwg-computing-network-routing-00.txt | ||||||||||||||
| The Challenges and Requirements for Routing in Computing Cluster network | ||||||||||||||
|
This document discusses the characteristics of computing cluster network, analyzes the challenges of employing routing mechanisms in it, summarizes the routing mechanism requirements for computing cluster network with high performance. It providing a discussion basis for future technological development. | |||||||||||||
| draft-li-rtgwg-distributed-lossless-framework-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-rtgwg-enhanced-ti-lfa-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-rtgwg-generalized-ipv6-tunnel-04.txt | ||||||||||||||
| Generalized IPv6 Tunnel (GIP6) | ||||||||||||||
|
This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. | |||||||||||||
| draft-li-rtgwg-gip6-protocol-ext-requirements-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-rtgwg-protocol-assisted-protocol-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-rtgwg-tte-02.txt | ||||||||||||||
| Tactical Traffic Engineering (TTE) | ||||||||||||||
|
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. | |||||||||||||
| draft-li-savnet-sav-yang-05.txt | ||||||||||||||
| YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) | ||||||||||||||
|
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. | |||||||||||||
| draft-li-savnet-source-prefix-advertisement-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-savnet-srsav-00.txt | ||||||||||||||
| Segment Routing Policy-Based Source Address Validation (SAV) Mechanism | ||||||||||||||
|
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. | |||||||||||||
| draft-li-sidrops-bicone-sav-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-sidrops-rpki-moasgroup-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-sidrops-rpki-repository-problem-statement-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-span-over-srv6-00.txt | ||||||||||||||
| SRv6 SPAN | ||||||||||||||
|
As an important means for operation and maintenance (O&M), mirroring is the most direct and comprehensive technology for capturing data streams and forwarding information. Compared with other visualization technologies, it can not only obtain the content of an entire packet, but also add forwarding information of a network device to a mirror packet and send the packet to a remote analysis server. | |||||||||||||
| draft-li-spring-sr-sfc-control-plane-framework-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-spring-srh-tlv-processing-programming-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-teas-composite-network-slices-03.txt | ||||||||||||||
| Realization of Composite IETF Network Slices | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. | |||||||||||||
| draft-li-tiptop-address-space-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liebsch-dmm-mts-01.txt | ||||||||||||||
| Mobile Traffic Steering | ||||||||||||||
|
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. | |||||||||||||
| draft-liest-nmrg-ndt-challenges-00.txt | ||||||||||||||
| Challenge: Network Digital Twin - Practical Considerations and Thoughts | ||||||||||||||
|
This document focuses on practical challenges associated with the design, creation and use of Network Digital Twins. According to the identified challenges, a set of suitable functional elements are described to overcome some of these challenges. Experiences from the design, development and evaluation of an SDN-based Network Digital Twin are described and conclude this document. | |||||||||||||
| draft-lihawi-ancp-protocol-access-extension-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lim-apv-03.txt | ||||||||||||||
| Advanced Professional Video | ||||||||||||||
|
This document describes bitstream format of Advanced Professional Video and decoding process of it. | |||||||||||||
| draft-lim-rtp-apv-00.txt | ||||||||||||||
| RTP payload format for APV | ||||||||||||||
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APC) codec. | |||||||||||||
| draft-lin-bfd-path-consistency-over-sr-03.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-lin-ccamp-gmpls-fgotn-applicability-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-idr-bgpls-sr-policy-headend-behavior-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-lin-idr-bgpls-te-policy-pm-04.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-lin-idr-cats-flowspec-ts-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-idr-distribute-service-metric-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-idr-sr-policy-admin-flags-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-lsr-flex-algo-metric-05.txt | ||||||||||||||
| Advertisement of Dedicated Metric for Flexible Algorithm in IGP | ||||||||||||||
|
This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. | |||||||||||||
| draft-lin-lsr-igp-car-02.txt | ||||||||||||||
| IGP Color-Aware Routing | ||||||||||||||
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. | |||||||||||||
| draft-lin-lsr-srv6-service-sid-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-mpls-ldp-holdtimer-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-pce-sr-policy-headend-behavior-00.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-lin-pce-srv6-segment-list-optimize-02.txt | ||||||||||||||
| PCEP Extension to Support SRv6 Segment List optimization | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for optimizing the arrangement of segment lists to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. | |||||||||||||
| draft-lin-pcep-sendholdtimer-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-spring-srv6-across-untrusted-domain-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lin-spring-srv6-aware-context-indicator-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lindblad-tlm-philatelist-02.txt | ||||||||||||||
| Philatelist,YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases | ||||||||||||||
|
Timestamped telemetry data is collected en masse today. Mature tools are typically used, but the data is often collected in an ad hoc manner. While the dashboard graphs look great, the resulting data is often of questionable quality, not well defined, and hard to compare with seemingly similar data from other organizations. This document proposes a standard, extensible, cross domain framework for collecting and aggregating timestamped telemetry data in a way that combines YANG, metadata and Time Series Databases to produce more transparent, dependable and comparable results. This framework is implemented in the Network Controller layer, but is rooted in data that is collected from all kinds of Network Elements and related systems. | |||||||||||||
| draft-lingga-i2nsf-analytics-interface-dm-04.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-lingga-opsawg-analytics-interface-dm-00.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-link-6man-gulla-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-linker-digital-emblem-02.txt | ||||||||||||||
| Problem Statement for a Digital Emblem | ||||||||||||||
|
In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark _physical_ assets. This enables military units to identify assets as respected and protected under international humanitarian law. This draft explores how one could apply the protective emblems to _digital_, network- connected infrastructure using a _digital emblem_, and defines the requirements of a digital emblem, emphasizing security requirements. Notably, a digital emblem has a unique combination of security requirements, namely, authentication, accountability, and a property that we call _covert inspection_. Covert inspection means that those wishing to authenticate assets as protected must be able to do so without revealing that they may attack unprotected entities. | |||||||||||||
| draft-lior-radius-prepaid-extensions-22.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-6man-aggregate-header-limit-problem-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-6man-icmp-verification-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-acme-rats-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-bess-srv6-evpn-validation-01.txt | ||||||||||||||
| Data Plane Failure Detection Mechanisms for EVPN over SRv6 | ||||||||||||||
|
This document proposes extension for ICMPv6 to detect data plane failures for EVPN over SRv6. | |||||||||||||
| draft-liu-bess-srv6-service-sid-anycast-flag-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-bess-srv6-service-sid-nffrr-flag-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-bier-uloop-04.txt | ||||||||||||||
| BIER Loop Avoidance using Segment Routing | ||||||||||||||
|
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. | |||||||||||||
| draft-liu-ccamp-optical2cloud-problem-statement-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-grow-bmp-over-quic-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-grow-bmp-rm-aggregated-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-idr-bgp-ls-srp-flexible-path-selection-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-idr-bgp-rpki-yang-00.txt | ||||||||||||||
| YANG Data Model for BGP about RPKI | ||||||||||||||
|
This document defines YANG data models for configuring and managing BGP information about Resource Public Key Infrastructure (RPKI). | |||||||||||||
| draft-liu-idr-bgp-sr-policy-cp-threshold-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-idr-bgpls-epe-te-pm-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-idr-bgpls-sr-p2mp-policy-distribution-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-idr-sr-segment-list-optimize-00.txt | ||||||||||||||
| BGP Extension for SR Segment List optimization | ||||||||||||||
|
This document introduces an optimization method for segment list arrangement the SR Policy TLV of the BGP Tunnel Encapsulation Attribute. This optimization solves the problem of the Segment Routing's penultimate segment node being unable to perform the penultimate Segment Pop (PSP) behavior when the egress node has both End SID and service SID encapsulated in Segment Routing Header's segment List. This solution adds an E-Flag to the SRv6 SID Endpoint Behavior sub-TLV carried in Segment List Sub-TLV of the SR Policy TLV. This optimization can improve the forwarding efficiency of data packets when End SID and Service SID are present. | |||||||||||||
| draft-liu-ippm-srv6-bandwidth-measurement-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-ipsecme-ikev2-mtu-dect-08.txt | ||||||||||||||
| IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension | ||||||||||||||
|
This document defines the IKEv2 Link Maximum Atomic Packet and Packet Too Big Extension to limit reassembly operations being performed by the egress security gateway. This extension enables an egress security gateway to notify its ingress counterpart that fragmentation is happening or that the received (and potentially reassembled) ESP packet is too big and thus cannot be decrypted. In both cases, the egress node provides Maximum Transmission Unit (MTU) information. Such information enables the ingress node to configure appropriately its Tunnel Maximum Transmission Unit - also designated as MTU or Tunnel MTU (TMTU) - to prevent fragmentation or too big packets to be transmitted. | |||||||||||||
| draft-liu-lamps-browser-webpki-cert-preservation-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-lamps-certification-path-validation-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-lamps-mechanism-updates-to-rfc-5280-06.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-liu-lsr-aggregate-header-limit-01.txt | ||||||||||||||
| Signaling Aggregate Header Size Limit via IGP | ||||||||||||||
|
This document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node to for efficient packet processing. Aggregate header limit is the total header size(e.g, in IPv6, it includes the IPv6 header chain as well as any headers that are part of network encapsulation that precedes the innermost transport layer) that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. | |||||||||||||
| draft-liu-mboned-adaptive-utom-01.txt | ||||||||||||||
| Adaptive Unicast to Multicast Forwarding | ||||||||||||||
|
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. | |||||||||||||
| draft-liu-nasr-architecture-01.txt | ||||||||||||||
| Network Attestation for Secure Routing (NASR) Architecture | ||||||||||||||
|
This document provides an architecture overview of NASR entities, interactive procedures and messages. | |||||||||||||
| draft-liu-nasr-requirements-03.txt | ||||||||||||||
| NASR Use Case and Requirements | ||||||||||||||
|
This document describes the use cases and requirements that guide the specification of a Network Attestation for Secure Routing framework (NASR). | |||||||||||||
| draft-liu-opsawg-cco-cm-requirement-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-pce-sr-policy-cp-threshold-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-pim-msdp-sendholdtimer-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-pim-msr6-encapsulation-and-forwarding-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-rtgwg-adaptive-routing-notification-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-rtgwg-mdt-in-high-bdp-01.txt | ||||||||||||||
| Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network | ||||||||||||||
|
This document describes the use cases and related requirements of Massive Data Transmission（MDT）in High Bandwidth-delay Product (BDP) Network. To achieve MDT, it is necessary to implement service identification and traffic record, network layer load balancing, transmission protocol optimization, etc. | |||||||||||||
| draft-liu-rtgwg-path-aware-remote-protection-02.txt | ||||||||||||||
| Path-aware Remote Protection Framework | ||||||||||||||
|
This document describes the framework of path-aware remote protection. | |||||||||||||
| draft-liu-sidrops-rpki-rtr-over-quic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-sidrops-rtr-yang-06.txt | ||||||||||||||
| YANG Data Model for RPKI to Router Protocol | ||||||||||||||
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). | |||||||||||||
| draft-liu-sm-for-openpgp-01.txt | ||||||||||||||
| Abstract | ||||||||||||||
|
This document introduces the Shang Mi(SM) cryptographic algorithm for openpgp protocol. | |||||||||||||
| draft-liu-spring-bfd-srv6-policy-encap-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-spring-nrp-id-in-srv6-segment-05.txt | ||||||||||||||
| NRP ID in SRv6 segment | ||||||||||||||
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. | |||||||||||||
| draft-liu-spring-sr-policy-flexible-path-selection-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-srv6ops-problem-summary-03.txt | ||||||||||||||
| SRv6 Deployment and Operation Problem Summary | ||||||||||||||
|
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. | |||||||||||||
| draft-liu-srv6ops-sr-protection-02.txt | ||||||||||||||
| Best Practices for Protection of SRv6 Networks | ||||||||||||||
|
This document describes the Best Practices for protection of Segment Routing Over IPv6 (SRv6) networks. | |||||||||||||
| draft-liu-teas-transport-network-slice-yang-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liu-teas-yang-srv6-te-topo-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-livingood-low-latency-deployment-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lizihan-hybrid-cloudlargelanguagemodel-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ll-idr-cats-bgp-extension-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-llg-opsawg-ipfix-over-quic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-loffredo-regext-epp-over-http-05.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-lopez-lake-edhoc-psk-02.txt | ||||||||||||||
| EDHOC PSK authentication | ||||||||||||||
|
This document specifies the Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. It describes the authentication processes, message flows, and security considerations of this authentication method. | |||||||||||||
| draft-lopez-opsawg-yang-provenance-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lopez-qirg-qi-multiplane-arch-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lopresti-open-cloud-mesh-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lou-manet-sturp-02.txt | ||||||||||||||
| Sloppy Topology Updates for ad-hoc Routing Protocols (STURP) | ||||||||||||||
|
This memo describes an approach to updating topologies in typical MANET-like environments, relying on what is termed 'sloppy updates' in the remainder of this document. Key to the approach is that updates are only initiated if existing communication relations may be effect by non-synchronized topology information, otherwise using the topology information as it exists. This 'sloppy' nature of the approach reduces the needed updates and the associated communication for them, thus increases efficiency as well as performance from a user perspective. | |||||||||||||
| draft-lou-rtgwg-sinc-03.txt | ||||||||||||||
| Signaling In-Network Computing operations (SINC) | ||||||||||||||
|
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. | |||||||||||||
| draft-lozano-icann-registry-interfaces-23.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lrss-bess-evpn-group-policy-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ls-idr-bgp-ls-service-metadata-04.txt | ||||||||||||||
| Distribution of Service Metadata in BGP-LS | ||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS. | |||||||||||||
| draft-lsr-prz-interop-flood-reduction-architecture-00.txt | ||||||||||||||
| Flooding Reduction Algorithm Interoperability Considerations | ||||||||||||||
|
In case multiple distributed (including a possible centralized one) flood reduction algorithms are deployed at the same time in an IGP domain the correctness of the overall solution preconditions certain co-operative behavior of involved algorithms. Under such conditions the correctness of the overall solution can be derived from resulting graph theoretical concepts easily. This document presents the necessary requirements on the deployed algorithms and the resulting framework. The situation of multiple algorithms in the network in steady state is per se not necessarily operationally desirable but must be, if minimal network disruption during such procedure is required, solved for possible migration scenarios caused by e.g. discovered defects or algorithm improvements. | |||||||||||||
| draft-lu-cats-smam-security-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lu-srv6ops-srv6-for-power-grid-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lucente-grow-bmp-offline-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lukianets-open-ethics-transparency-protocol-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lundblade-cbor-cie-00.txt | ||||||||||||||
| Common Interoperable Encoding (CIE) | ||||||||||||||
|
CBOR allows variable serialization to accommodate varying use cases in constrained environments, but leaves it without a default interoperable serialization. Here a base interoperability serialization is defined that should usable for a majority of CBOR based protocols. | |||||||||||||
| draft-lxin-quic-socket-apis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lz-bess-srv6-service-capability-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ma-cats-computing-authenticity-evaluation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ma-netmod-yang-config-template-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ma-teas-ietf-network-slice-deployment-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mackenzie-bess-evpn-l3mh-proto-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mackey-nmop-kg-for-netops-01.txt | ||||||||||||||
| Knowledge Graph Framework for Network Operations | ||||||||||||||
|
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. | |||||||||||||
| draft-madi-sidrops-partial-validation-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mahy-mimi-app-components-00.txt | ||||||||||||||
| Application State Components for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
TODO Abstract | |||||||||||||
| draft-mahy-mimi-pseudonyms-00.txt | ||||||||||||||
| Some pseudonymous privacy flows for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
The MIMI protocol has a baseline level of metadata privacy, which can be made more private through the optional use of per-room pseudonyms. This document describes three of many possible flows that use pseudonyms for enhanced privacy. It also discusses some ways that spam and abuse prevention mechanisms can work in conjunction with pseudonyms. | |||||||||||||
| draft-mahy-mls-gce-diff-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mahy-mls-member-proof-00.txt | ||||||||||||||
| A membership proof extensions for the Messaging Layer Security (MLS) Protocol | ||||||||||||||
|
This document describes an MLS safe extension that members of a group can use to assert membership to non-members. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://rohanmahy.github.io/mls-member-proof/draft-mahy-member- proof.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mls-member-proof/. Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/mls-member-proof. | |||||||||||||
| draft-mahy-mls-ratchet-tree-options-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mahy-mls-semiprivatemessage-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mahy-vcon-mimi-messages-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-maldant-spice-oidc-cwt-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-malhotra-bess-evpn-centralized-anycast-gw-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mankamana-pim-pfm-sd-extension-evpn-mh-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-many-deepspace-dns-isolated-networks-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-many-deepspace-ip-architecture-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-many-deepspace-ip-assessment-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-many-deepspace-quic-profile-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-marcas-nmop-knowledge-graph-yang-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-martin-grow-rpki-generated-loa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m46a-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m46e-fp-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m46e-pr-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m46e-pt-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m46t-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-m4p6e-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-me6a-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-me6e-fp-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-me6e-pr-18.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-mslb-17.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-oht-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-oht-mh-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-matsuhira-pia-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mattsson-cfrg-aes-gcm-sst-12.txt | ||||||||||||||
| Galois Counter Mode with Secure Short Tags (GCM-SST) | ||||||||||||||
|
This document defines the Galois Counter Mode with Secure Short 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 Q, the derivation of fresh subkeys H and Q 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 unicast security protocols with replay protection and addresses the strong industry demand for fast encryption with less overhead and secure short tags. This document registers several instances of GCM-SST using Advanced Encryption Standard (AES) and Rijndael-256-256. | |||||||||||||
| draft-mb-mpls-ioam-dex-09.txt | ||||||||||||||
| Supporting In-Situ Operations,Administration,and Maintenance Direct Export Using MPLS Network Actions | ||||||||||||||
|
In-Situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information that can be used to calculate various performance metrics. IOAM Direct Export (IOAM-DEX) is one of the IOAM Option types, in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the on-path operational state, and telemetry information can be collected using IOAM-DEX Option in combination with MNA. | |||||||||||||
| draft-mcbride-rtgwg-bgp-blockchain-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcbride-srv6ops-srv6-deployment-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcd-ivy-entitlements-inventory-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcfadden-cnsldtn-effects-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcfadden-consolidation-taxonomy-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mclaggan-wccp-v2rev1-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcmillion-mimi-delivery-service-00.txt | ||||||||||||||
| Robust and Privacy-Preserving Delivery Service | ||||||||||||||
|
This document describes a federated MLS Delivery Service (DS) for use in the More Instant Messaging Interoperability (MIMI) protocol. The DS provides for the delivery of KeyPackages, Welcome messages, and group handshake/application messages. | |||||||||||||
| draft-mcnally-deterministic-cbor-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcnally-envelope-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mediaman-6838bis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melnikov-sasl2-02.txt | ||||||||||||||
| Extensible Simple Authentication and Security Layer (SASL) | ||||||||||||||
|
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. | |||||||||||||
| draft-melnikov-scram-bis-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melnikov-scram-sha-512-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melnikov-scram-sha3-512-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-menon-svr-07.txt | ||||||||||||||
| Juniper's Secure Vector Routing (SVR) | ||||||||||||||
|
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. | |||||||||||||
| draft-meynell-panrg-scion-deployment-00.txt | ||||||||||||||
| SCION Deployment Issues | ||||||||||||||
|
TODO Abstract here | |||||||||||||
| draft-meynell-panrg-scion-research-questions-01.txt | ||||||||||||||
| SCION Research Questions | ||||||||||||||
|
This draft intends to summarize all SCION related questions which are deemed important to be answered for SCION to properly work at Internet scale. The set of questions is at the moment not comprehensive, but we intend them to initiate a discussion to determine which questions should remain here, and which ones are missing. When appropriate, some example solutions can be provided for the community to determine whether said solutions are adequate or not. | |||||||||||||
| draft-mglt-ipsecme-dscp-np-01.txt | ||||||||||||||
| Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification | ||||||||||||||
|
IPsec supports "classifier" mechanism to send traffic with specific Differentiated Services Field Codepoints (DSCP) over different tunnels. However, such classification is not explicitly notified to the other peer. This document specifies the DSCP Notification Payload, which, in a CREATE_CHILD_SA Exchange, explicitly mentions which DSCP code points will be tunneled in the newly created tunnel. | |||||||||||||
| draft-mh-6man-icmpv6-reflection-01.txt | ||||||||||||||
| Internet Control Message Protocol (ICMPv6) Reflection | ||||||||||||||
|
This document describes the ICMPv6 Reflection utility. ICMPv6 Reflection uses a request-response handshake that is similar to ICMPv6 Echo, except that after a request is sent, the corresponding reply includes the request message itself or a subset of its fields as specified in the request. Specifically, the IPv6 header of the request message and its IPv6 extension headers, if they are present, can be included in the reply. Network operators can use ICMPv6 Reflection to determine how IPv6 extension headers have been altered by transit nodes. | |||||||||||||
| draft-mhkk-dmm-mup-architecture-01.txt | ||||||||||||||
| Mobile User Plane Architecture for Distributed Mobility Management | ||||||||||||||
|
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. | |||||||||||||
| draft-miao-ccwg-hpcc-info-03.txt | ||||||||||||||
| Inband Telemetry for HPCC++ | ||||||||||||||
|
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. | |||||||||||||
| draft-michel-remote-terminal-http3-00.txt | ||||||||||||||
| Remote terminal over HTTP/3 connections | ||||||||||||||
|
The secure shell (SSH) traditionally offers its secure services over an insecure network using the TCP transport protocol. This document defines mechanisms to access remote terminals by running the SSH Connection protocol over HTTP/3 using Extended CONNECT. Remote terminals over HTTP/3 enables additional benefits such as the scalability offered by HTTP multiplexing, relying on TLS for secure channel establishment leveraging X.509 certificates, HTTP Authentication schemes for client and server authentication, UDP port forwarding and stronger resilience against packet injection attacks and middlebox interference. | |||||||||||||
| draft-mimi-discovery-requirements-00.txt | ||||||||||||||
| MIMI Discovery Requirements | ||||||||||||||
|
This document defines requirements for the discovery problem within the More Instant Messaging Interoperability (MIMI) working group. 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. | |||||||||||||
| draft-mirsky-mpls-stamp-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-misell-grow-rpki-peering-api-discovery-00.txt | ||||||||||||||
| A Profile for Peering API Discovery via the RPKI | ||||||||||||||
|
The Peering API currently under discussion in the GROW Working Group does not provide a mechanism for discovering the API endpoints that an ASN uses to accept peering requests. This document defines a new RPKI Signed Object to publicise this endpoint and allow discovery. Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.molgen.mpg.de/q/rpki-peering-api-discovery. | |||||||||||||
| draft-misell-rpki-bpki-key-rollover-00.txt | ||||||||||||||
| A BPKI key rollover protocol for the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document extends the RPKI setup protocol to allow the server and client to update their Trust Anchor CA keys in-band. | |||||||||||||
| draft-mishra-6man-variable-iids-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mishra-idr-v4-islands-v6-core-4pe-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mishra-spring-inter-domain-routing-arch-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mishra-srv6ops-inter-domain-routing-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mishra-srv6ops-inter-domain-routing-use-case-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mishra-v6ops-variable-iids-problem-statement-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-momoka-dnsop-3901bis-06.txt | ||||||||||||||
| 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. It expands on RFC 3901 by now suggesting authoritative and recursive resolvers to operate on 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. | |||||||||||||
| draft-mongrain-sipcore-siprec-fix-mediatype-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moonesamy-bcp83-bis-00.txt | ||||||||||||||
| Suspending Posting Rights | ||||||||||||||
|
The practice for revoking and restoring posting rights is specified in RFC 3683. The discussions for revoking posting rights stirred controversy. This document specifies a procedure for suspending posting rights to all written channels of communication used for the IETF Standards Process. This document obsoletes RFC 3683. | |||||||||||||
| draft-morand-http-digest-2g-aka-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moshiko-bgp-prefixlist-dynamic-config-00.txt | ||||||||||||||
| BGP Signaled Prefix-List For Dynamic Configuration | ||||||||||||||
|
This document defines a new BGP extended community attribute, termed the "Prefix-List Community," which allows the dynamic assignment of prefixes to named prefix-lists via BGP signaling. The proposed extension enhances the configuration and operational flexibility of prefix-lists in routing policies by associating them with community attributes directly within BGP routes. | |||||||||||||
| draft-mosko-icnrg-ccnxchunking-03.txt | ||||||||||||||
| CCNx Content Object Chunking | ||||||||||||||
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. | |||||||||||||
| draft-moskowitz-drip-a2x-adhoc-session-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-drip-crowd-sourced-rid-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-drip-efficient-a2g-comm-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-drip-operator-privacy-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-drip-secure-nrid-c2-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-drip-stateless-nrid-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-hip-fast-mobility-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mouris-cfrg-mastic-03.txt | ||||||||||||||
| The Mastic VDAF | ||||||||||||||
|
This document describes Mastic, a two-party VDAF for the following secure aggregation task: each client holds an input 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. | |||||||||||||
| draft-mpmz-bess-mup-safi-04.txt | ||||||||||||||
| BGP Extensions for the Mobile User Plane (MUP) SAFI | ||||||||||||||
|
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. | |||||||||||||
| draft-mularczyk-mls-splitcommit-00.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-mwag-dske-01.txt | ||||||||||||||
| The Distributed Symmetric Key Establishment (DSKE) Protocol | ||||||||||||||
|
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. | |||||||||||||
| draft-mzanaty-moq-loc-04.txt | ||||||||||||||
| Low Overhead Media Container | ||||||||||||||
|
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. | |||||||||||||
| draft-mzhang-nfsv4-recursively-setting-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-nainar-mpls-lsp-ping-yang-06.txt | ||||||||||||||
| YANG Data Model for MPLS LSP Ping | ||||||||||||||
|
This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. | |||||||||||||
| draft-nandakumar-deepspace-moq-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-nandy-chethan-subramanian-mtrace-layer2-00.txt | ||||||||||||||
| Mtrace2 L2 Extensions: Traceroute Facility for Layer 2 Multicast | ||||||||||||||
|
This document describes extensions to IP multicast traceroute facility, named Mtrace2 version 2 (Mtrace2), to include traced path for Layer 2 multicast. Mtrace2 allows tracing the path from Last-Hop Router (LHR) to a source. Tracing the Layer 2 path from LHR till the actual receivers requires special implementations on the part of switches in the Layer 2 path. This specification describes the required functionality in multicast routers and switches. This feature functions along with the Layer 2 multicast protocols like IGMP (Internet Group Management Protocol) Snooping and MLD(Multicast Listener Discovery) Snooping. | |||||||||||||
| draft-navarre-quic-flexicast-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-netana-netconf-notif-envelope-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-netana-netconf-yp-transport-capabilities-00.txt | ||||||||||||||
| YANG Notification Transport Capabilities | ||||||||||||||
|
This document proposes a YANG module for YANG notifications transport capabilities which augments "ietf-system-capabilities" YANG module defined in [RFC9196] and 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. | |||||||||||||
| draft-nh-sr-hsfc-usecases-requirements-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-nichols-iotops-defined-trust-transport-07.txt | ||||||||||||||
| Defined-Trust Transport (DeftT) Protocol for Limited Domains | ||||||||||||||
|
This document is not an Internet Standards Track specification and does not enjoy IETF consensus. It is published for examination, evaluation, and experimentation. The Defined-trust Transport (DeftT) framework is designed to provide default-deny communications for certain types of Limited Domains (RFC8799) used for Operational Technology (OT) networks and, in particular, Critical Infrastructure networking. DeftT is designed to express and enforce application- and deployment-specific integrity, authentication, access control and behavior constraints directly in its protocol modules. It enables secure and completely self-contained (e.g., no external identity servers or certificate authorities) overlay networks where credentialed members can join and leave at any time. Security is not optional and members preconfigured only with their individual cryptographically secured identities and the secured communication rules independently authenticate other members' identities and their role- and attribute-specific communications. DeftT is an integrated trust management, multi-party transport that synchronizes collections of secured information across all members of its domain. It uses a many-to-many synchronization primitive rather than source-destination send-and-acknowledgement. Packets are not routable and information only leaves its originating subnet if it is both explicitly permitted in the secured rules and there is a member element (relay) constructed to move validated information containers across subnets. DeftT provides default deny networking for closed communities with dynamic membership and a collection-based transport that is efficient on broadcast media. DeftT is part of a Defined- trust Communications approach with an example implementation available. Combined with IPv6 multicast and modern hardware-based methods for securing keys and code, it can provide a foundation for secure and efficient communications in Limited Domains, particularaly in Critical Infrastructure domains. | |||||||||||||
| draft-nir-ipsecme-big-payload-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-nottingham-http-availability-hints-01.txt | ||||||||||||||
| HTTP Availability Hints | ||||||||||||||
|
This specification defines availability hints, a new class of HTTP responses headers that augment the information in the Vary header field. | |||||||||||||
| draft-nottingham-public-resolver-errors-00.txt | ||||||||||||||
| Extensions for DNS Public Resolvers | ||||||||||||||
|
[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. 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. | |||||||||||||
| draft-nser-vrrp-sbfd-00.txt | ||||||||||||||
| Fast failure detection in VRRP with S-BFD | ||||||||||||||
|
Since the VRRP protocol depends on the availability of Layer 3 IPvX connectivity between redundant peers, the VRRP protocol can interact with the variant of S-BFD as described in [RFC7881] to achieve a much faster failure detection. This document describes how to extend the Virtual Router Redundancy Protocol (VRRP) to support Seamless Bidirectional Forwarding Detection (S-BFD) as a detection system for Primary Router failure. To announce the use of this implementation, a new type (Section 5.2.2.) of VRRP packet and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the SBFD Discriminators is also implemented. | |||||||||||||
| draft-nurpmeso-dkim-access-control-diff-changes-00.txt | ||||||||||||||
| DKIM Access Control and Differential Changes | ||||||||||||||
|
This document specifies a bundle of DKIM (RFC 6376) adjustments and extensions. 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 only based upon that. | |||||||||||||
| draft-nurpmeso-dkim-algo-adaed25519-01.txt | ||||||||||||||
| DKIM Signing Algorithm AdaEd25519-SHA256 | ||||||||||||||
|
This memo 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 (draft-nurpmeso- dkim-hash-adaptivity). Private and public keys are identical, and can be used interchangeably. | |||||||||||||
| draft-nurpmeso-dkim-hash-adaptivity-01.txt | ||||||||||||||
| DKIM Hash Algorithm Adaptivity | ||||||||||||||
|
DKIM (RFC 6376, section 3.7) defines how "data-hash" is generated as input to a RSA (RFC 8017) "sig-alg". Modern signature algorithms (for example EdDSA, RFC 8032) include extensive data hashing as part of the signing process. This memo allows DKIM signing algorithm "data-hash" adaptivity, taking advantage of algorithm progress and digital signature API reality. | |||||||||||||
| draft-nurpmeso-smtp-tls-srv-01.txt | ||||||||||||||
| Secure SMTP/TLS SRV Announcement | ||||||||||||||
|
It is described how DNS (RFC 1035) SRV (RFC 2782) records announce availability of TLS (RFC 8446) enabled Secure SMTP (RFC 3207, RFC 5321). | |||||||||||||
| draft-oh-nmrg-ai-adp-02.txt | ||||||||||||||
| AI-Based Distributed Processing Automation in Digital Twin Network | ||||||||||||||
|
This document discusses the use of AI technology and digital twin technology to automate the management of computer network resources distributed across different locations. Digital twin technology involves creating a virtual model of real-world physical objects or processes, which is utilized to analyze and optimize complex systems. In a digital twin network, AI-based network management by automating distributed processing involves utilizing deep learning algorithms to analyze network traffic, identify potential issues, and take proactive measures to prevent or mitigate those issues. Network administrators can efficiently manage and optimize their networks, thereby improving network performance and reliability. AI-based network management, utilizing digital twin network technology, also aids in optimizing network performance by identifying bottlenecks in the network and automatically adjusting network settings to enhance throughput and reduce latency. By implementing AI-based network management through automated distributed processing, organizations can improve network performance, and reduce the need for manual network management tasks. | |||||||||||||
| draft-oiwa-secure-hybrid-network-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-oran-icnrg-flowbalance-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-org-trust-relationship-protocol-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-orr-wlan-security-architectures-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ounsworth-lamps-pq-external-pubkeys-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ovmd-netmod-dmanm-00.txt | ||||||||||||||
| An Approach to Expose 'Device Models'-as-'Network Models' | ||||||||||||||
|
This document describes an approach for exposing Device Models as Network Models (DMaNM). In particular, this document provides guidance for structuring a data model to facilitate the reuse of device models within the customer-facing interface of Software- Defined Networking (SDN) controllers. The objective of this approach is to enhance the reusability of device models in various network scenarios and ease the mapping between network/service models with device models and ensure lossless mapping between the various layers. | |||||||||||||
| draft-p-6man-deterministic-eh-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-palanivelan-bfd-v2-gr-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-palet-v6ops-ipv6-only-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-palmero-ivy-dmalmo-02.txt | ||||||||||||||
| Data Model for Asset Lifecycle Management and Operations | ||||||||||||||
|
This document includes a data model for assets lifecycle management and operations. The primary objective of the data model is to measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. This model is based on the information model introduced in "Asset Lifecycle Management and Operations: A Problem Statement" (ALMO) [I-D.draft-palmero-opsawg-ps-almo-00] IETF draft. | |||||||||||||
| draft-palmero-ivy-ps-almo-02.txt | ||||||||||||||
| Asset Lifecycle Management and Operations: A Problem Statement | ||||||||||||||
|
This document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model. The primary objective for this problem statement document is to validate and prove that the framework can measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. | |||||||||||||
| draft-pan-dnsop-explicit-forged-answer-signal-01.txt | ||||||||||||||
| Explicit Forged Answer Signal | ||||||||||||||
|
This document describes about the forged answer provided by recursive resolver. Client could protect user on security and privacy more efficiently if recursive resolver gives explict signal in the forged answer. | |||||||||||||
| draft-pan-ipsecme-anti-replay-notification-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pang-sfc-interface-cnc-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pang-v6ops-usecases-ipv6-monitoring-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pantos-hls-rfc8216bis-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pardue-capsule-ext-guidance-01.txt | ||||||||||||||
| Guidance for HTTP Capsule Protocol Extensibility | ||||||||||||||
|
This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. | |||||||||||||
| draft-pardue-httpbis-identity-digest-00.txt | ||||||||||||||
| HTTP Identity 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 Identity-Digest and Want-Identity- Digest fields complement existing integrity fields for this purpose. | |||||||||||||
| draft-parecki-oauth-client-id-metadata-document-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-parecki-oauth-client-id-scheme-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-parecki-oauth-global-token-revocation-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-parecki-oauth-identity-assertion-authz-grant-02.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-park-nmrg-ibn-network-management-srv6-02.txt | ||||||||||||||
| Intent-Based Network Management in SRv6 Networks | ||||||||||||||
|
This document describes secure network management in Segment Routing version six (SRv6) networks. It proposes a framework empowered with Intent-Based Networking (IBN). The Intent-Based Network Management (IBNM) in this document specifies an architectural framework with system components and interfaces. Also, this framework builds on Interface to Network Security Functions (I2NSF). | |||||||||||||
| draft-pauly-httpbis-geoip-hint-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pauly-v6ops-happy-eyeballs-v3-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pb-6man-deterministic-crh-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pcmy-grow-bmp-adj-ribs-filtered-00.txt | ||||||||||||||
| Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers | ||||||||||||||
|
Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. | |||||||||||||
| draft-pedro-nmrg-ai-framework-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-peetterr-dnsop-parent-side-auth-types-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pelov-schc-fragmentation-fec-rule-format-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pelov-sid-procedure-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-peng-6man-tracing-option-06.txt | ||||||||||||||
| Tracing process in IPv6 VPN Tunneling Networks | ||||||||||||||
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. | |||||||||||||
| draft-peng-detnet-deadline-based-forwarding-13.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-peng-detnet-packet-timeslot-mechanism-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-peng-detnet-policing-jitter-control-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-peng-detnet-tqf-controller-plane-00.txt | ||||||||||||||
| Timeslot Queueing and Forwarding (TQF) Control Plane | ||||||||||||||
|
To achive DetNet QoS in IP/MPLS network and meet the large scaling requirements, timeslot queueing and forwarding (TQF) mechanism for enhancing TAS is introduced. This document describes the controller plane function (CPF) for TQF mechanism. | |||||||||||||
| draft-peng-lsr-deterministic-traffic-engineering-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-perkins-irtf-code-of-conduct-06.txt | ||||||||||||||
| IRTF Code of Conduct | ||||||||||||||
|
This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and diversity of participation. Through this code of conduct, the IRTF will continue to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect. This document is a product of the Internet Research Steering Group (IRSG). | |||||||||||||
| draft-perkins-manet-aodvv2-05.txt | ||||||||||||||
| Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing | ||||||||||||||
|
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. | |||||||||||||
| draft-perkins-role-of-irtf-02.txt | ||||||||||||||
| The Role of the Internet Research Task Force (IRTF) | ||||||||||||||
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This document is a product of the Internet Research Steering Group (IRSG). | |||||||||||||
| draft-petithuguenin-computerate-specification-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-petithuguenin-rfc-ontology-05.txt | ||||||||||||||
| An Ontology for RFCs | ||||||||||||||
|
This document defines an ontology that describes the specifications published by the RFC Editor, together with ancillary documents. | |||||||||||||
| draft-petithuguenin-ufmrg-formal-sexpr-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-petithuguenin-xml2rfc-asciidoc-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-petra-green-api-00.txt | ||||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| draft-petra-path-energy-api-02.txt | ||||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| draft-petrie-vcon-04.txt | ||||||||||||||
| The CDDL format for vCon - Conversation Data Container | ||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | |||||||||||||
| draft-pham-mls-additional-wire-formats-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pignataro-green-enviro-icmp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pignataro-green-enviro-sust-terminology-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-piraux-quic-additional-addresses-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-piraux-tcp-ao-tls-02.txt | ||||||||||||||
| Opportunistic TCP-AO with TLS | ||||||||||||||
|
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. | |||||||||||||
| draft-poidt-teas-actn-poi-assurance-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-polli-restapi-ld-keywords-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-power-metadata-expression-language-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ppsenak-lsr-igp-reverse-spf-algo-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-prabel-jose-pq-composite-sigs-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-prorock-spice-cwt-traceability-claims-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-przygienda-rift-adrift-00.txt | ||||||||||||||
| AD-RIFT: Adaptive RIFT | ||||||||||||||
|
Adaptive RIFT (AD-RIFT for short) extends RIFT to carry additional link and node information, primarily traffic engineering related. This enables the southbound computation to optimally place traffic depending on available resources and usage. Additionally, a selective disaggregation, similar to negative disaggregation, is introduced that allows to balance northbound forwarding toward specific prefixes between nodes at the same level depending on resources available. | |||||||||||||
| draft-psarkar-lsvr-bgp-spf-impl-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pskim-quic-pmtu-algorithms-00.txt | ||||||||||||||
| Path MTU Algorithms for QUIC | ||||||||||||||
|
This draft consider a couple of algorithms for Path MTU (PMTU) in QUIC to discovery optimal PMTU and resolve PMTU black hole problem. Fistly, a passive probing approach is adopted to discover the PMTU. The process of discovering the PMTU is not performed separately, but is performed simultaneously in the actual application data communication. That is, the actual application data is allowed to be carried in the process of discovering the PMTU. A probe packet is defined newly using 1-RTT packet which includes actual application data as well as a short packet header and a PING_EXT frame. Until the optimal PMTU is discovered, the size of the probe packet is changed according to the size of the PMTU candidate. Secondly, a PMTU black hole problem in secure and reliable transport protocol is discussed and a possible solution can be suggested from existing researches. | |||||||||||||
| draft-puhl-6man-ndp-vba-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pwouters-crypto-current-practices-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pwouters-ipsecme-delete-info-02.txt | ||||||||||||||
| IKEv2 support for specifying a Delete notify reason | ||||||||||||||
|
This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). | |||||||||||||
| draft-qian-detnet-preof-ioam-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-qu-identifier-sm3-for-tsig-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ra-emu-pqc-eapaka-01.txt | ||||||||||||||
| 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 making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ- KEMs). | |||||||||||||
| draft-rabadan-bess-evpn-inter-domain-opt-b-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rabnag-bess-evpn-anycast-aliasing-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rabnic-bess-evpn-mcast-eeg-04.txt | ||||||||||||||
| EVPN Multicast Forwarding for EVPN to EVPN Gateways | ||||||||||||||
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. | |||||||||||||
| draft-rajaram-netmod-yang-cfg-template-framework-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ramakrishna-satp-data-sharing-02.txt | ||||||||||||||
| Protocol for Requesting and Sharing Views across Networks | ||||||||||||||
|
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. | |||||||||||||
| draft-ramakrishna-satp-views-addresses-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ramanathan-lisp-savi-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rankin-ccsv-02.txt | ||||||||||||||
| 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". | |||||||||||||
| draft-rathnayake-xml2rfc-unicode-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rbickhart-evpn-ip-mac-proxy-adv-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rbw-add-encrypted-dns-forwarders-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rbw-home-servers-00.txt | ||||||||||||||
| Identifying and Authenticating Home Servers: Requirements and Solution Analysis | ||||||||||||||
|
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. | |||||||||||||
| draft-rc-detnet-data-unit-groups-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rcr-opsawg-operational-compute-metrics-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rd-bess-evpn-mcast-leave-update-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-realvnc-websocket-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-reddy-cose-jose-pqc-hybrid-hpke-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-reddy-ipsecme-ikev2-pqc-auth-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-reddy-pfsd-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-reddy-tls-composite-mldsa-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-reddy-tls-slhdsa-00.txt | ||||||||||||||
| Use of SLH-DSA in TLS 1.3 | ||||||||||||||
|
This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. | |||||||||||||
| draft-reddy-uta-pqc-app-04.txt | ||||||||||||||
| Post-Quantum Cryptography Recommendations for Applications | ||||||||||||||
|
Post-quantum cryptography introduces new challenges for applications, end users, and system administrators. This document outlines characteristics unique to application protocols and provides best practices for deploying Quantum-Ready usage profiles in applications utilizing TLS. | |||||||||||||
| draft-rescorla-tls-rfc9147bis-00.txt | ||||||||||||||
| The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. | |||||||||||||
| draft-retana-idr-bgp-quic-05.txt | ||||||||||||||
| BGP over QUIC | ||||||||||||||
|
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency. | |||||||||||||
| draft-rfcxml-general-template-standard-00.txt | ||||||||||||||
| hardware divvying | ||||||||||||||
|
a proposal for hardware divvying (specifically in the case of RAM) | |||||||||||||
| draft-rfcxml-rfc-swl-103k-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-richards-fake-draft-00.txt | ||||||||||||||
| Fake Draft for Testing | ||||||||||||||
|
This draft is for testing porpoises only. | |||||||||||||
| draft-richardson-netmod-atrest-extensions-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-richter-webtransport-websocket-01.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-rigatoni-lsr-isis-fragment-timestamping-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rivest-sexp-12.txt | ||||||||||||||
| Simple Public Key Infrastructure (SPKI) S-Expressions | ||||||||||||||
|
This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI, RFC 2692) certificates with the intent that it be more widely applicable. It has been and is being used elsewhere. There are multiple implementations in a variety of programming languages. Uses of this representation are referred to in this document as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: it gives a "canonical form" for them, describes two "transport" representations, and also describe an "advanced" format for display to people. | |||||||||||||
| draft-rjt-scone-conformance-signal-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rmacklem-nfsv4-posix-acls-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-robert-mimi-attachments-02.txt | ||||||||||||||
| MIMI Attachments | ||||||||||||||
|
This document describes MIMI Attachments. | |||||||||||||
| draft-rokui-ccamp-actn-wdm-pluggable-modelling-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rosen-ecrit-emergency-registries-02.txt | ||||||||||||||
| Emergency Registries | ||||||||||||||
|
Multiple emergency services standards organizations are developing specifications based on IETF emergency calling and other IETF protocols. There is a desire among these organizations to use common registries, not tied to a particular country or national Standards Development Organization (SDO), in the long term pursuit of a single worldwide standard. This document asks IANA to create a set of registries and provides processes for expanding the set and populating them. | |||||||||||||
| draft-rosenberg-vcon-cc-usecases-01.txt | ||||||||||||||
| Contact Center Use Cases and Requirements for VCON | ||||||||||||||
|
This document outlines use cases and requirements for the exchange of VCONs (Virtual Conversation) within contact centers. A VCON is a standardized format for the exchange of call recordings and call metadata. Today, call recordings are exchanged between different systems within the contact center. Often, these are done using proprietary file formats and proprietary APIs. By using VCONs, integration complexity can be reduced. | |||||||||||||
| draft-rosomakho-wimse-tokentranslation-reqs-00.txt | ||||||||||||||
| Requirements for WIMSE Token Translation | ||||||||||||||
|
This document outlines the requirements for workload token translation within the context of the Workload Identity in Multi System Environments (WIMSE). Token translation may be required for interoperability between workloads or for complying with security requirements of multi-system environments. This requirement document considers various aspects of token translation, such as changes in token format, content encoding, cryptographic properties, and context embedding. Additionally, this document raises security considerations to be addressed by specific token translation implementations, including replay attacks, access control, and privacy concerns. | |||||||||||||
| draft-rpc-errata-process-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rpc-rfc7322bis-01.txt | ||||||||||||||
| RFC Style Guide | ||||||||||||||
|
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 | |||||||||||||
| draft-rsalz-2026bis-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rsalz-2418bis-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rsalz-crypto-registries-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rswg-rfc7990-updates-12.txt | ||||||||||||||
| RFC Formats and Versions | ||||||||||||||
|
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published. This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. | |||||||||||||
| draft-rswg-rfc7997bis-03.txt | ||||||||||||||
| The Use of Non-ASCII Characters in RFCs | ||||||||||||||
|
The RFC Series has evolved to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of RFCs is now in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes requirements and guidelines for the RFC Editor regarding the use of non-ASCII characters in RFCs. This document obsoletes RFC 7997. The differences reflect changes in the practices of the RFC series since RFC 7997 was published, and makes further changes based on agreements in the IETF community about what characters are allowed in RFCs. [[ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ]] | |||||||||||||
| draft-ruan-scone-use-cases-and-requirements-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ruas-cfrg-ecdp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ruoska-encoding-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-rwbr-sconepro-flow-metadata-02.txt | ||||||||||||||
| Flow Metadata for Collaborative Host/Network Signaling | ||||||||||||||
|
This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. | |||||||||||||
| draft-ryoo-detnet-ontime-forwarding-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sabitzer-sapi-password-change-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sajassi-bess-evpn-fabric-migration-01.txt | ||||||||||||||
| EVPN Underlay Network Migration From IPv4 to IPv6 | ||||||||||||||
|
EVPN [RFC7432] and [RFC8365] has become the standard defacto technology/solution used in Enterprise, Data Center, and Service Provider networks because of its multi-tenancy, flexible multi-homing capabilities, efficient utilization of network bandwidth, support of workload mobility, flexible workload placement, etc. across many different types of services/VPNs. Some operators have deployed IPv4 underlay network/fabric and now plan to migrate to IPv6. This document describes the procedures to achieve such migration seamlessly. | |||||||||||||
| draft-sajassi-bess-evpn-first-hop-security-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sajassi-bess-evpn-umr-mobility-02.txt | ||||||||||||||
| 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.. | |||||||||||||
| draft-sajassi-bess-rfc8317bis-03.txt | ||||||||||||||
| Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) | ||||||||||||||
|
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. | |||||||||||||
| draft-salih-spring-srv6-inter-domain-sids-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-salter-ipsecme-sha3-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-samuelson-irc-v3-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sarischo-6gip-aiml-security-privacy-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-saucez-lisp-8111bis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-saum-evpn-lsp-ping-extension-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-saum-nvo3-mtu-propagation-over-evpn-overlays-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-saumthimma-evpn-ip-binding-sync-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-savage-ppm-3phm-mpc-01.txt | ||||||||||||||
| Efficient Protocols for Binary Fields in the 3-Party Honest Majority MPC Setting | ||||||||||||||
|
A three party, honest majority system provides the most efficient protocols for Multiparty Computation (MPC). This document describes a concrete instantiation of addition and multiplication protocols that provide strong guarantees of security. The multiplication protocol provides low communication and computation costs, with addition being almost free. Any single dishonest party is detected with high probability. | |||||||||||||
| draft-sawant-capport-api-state-enhancement-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sawant-eap-ppt-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-saxe-wimse-token-exchange-and-translation-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-sayre-modpod-excellent-02.txt | ||||||||||||||
| Be Excellent To Each Other | ||||||||||||||
|
The greatest and least heinous of all golden rules. | |||||||||||||
| draft-sbriz-identity-trust-system-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schanzen-r5n-06.txt | ||||||||||||||
| The R5N Distributed Hash Table | ||||||||||||||
|
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. | |||||||||||||
| draft-schinazi-httpbis-wrap-up-01.txt | ||||||||||||||
| The HTTP Wrap Up Capsule | ||||||||||||||
|
HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. | |||||||||||||
| draft-schinazi-masque-proxy-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schinazi-update-on-milestones-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schmutzer-bess-bitstream-vpws-signalling-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-schmutzer-pals-ple-signaling-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schoen-intarea-unicast-0-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schoen-intarea-unicast-127-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schoen-intarea-unicast-240-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schoen-intarea-unicast-lowest-address-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-schott-sip-avors-02.txt | ||||||||||||||
| Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications | ||||||||||||||
|
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. | |||||||||||||
| draft-seemann-quic-address-discovery-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-seemann-tsvwg-udp-fragmentation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sehgal-scim-delta-query-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-serafin-lake-ta-hint-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-sfluhrer-cfrg-ml-kem-security-considerations-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shafranovich-rfc4180-bis-07.txt | ||||||||||||||
| Common Format and MIME Type for Comma-Separated Values (CSV) Files | ||||||||||||||
|
This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". | |||||||||||||
| draft-shamim-moq-time-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sheng-lsvr-bgp-spf-for-sdwan-02.txt | ||||||||||||||
| Usage of BGP-LS-SPF in Multi-segment SD-WAN | ||||||||||||||
|
This document introduces the usage of BGP-LS-SPF protocol in multi- segment SD-WAN scenarios. It allows SD-WAN tunnels to be published as logical links, which can cross the internet, MPLS networks, and various operator network. The BGP-LS-SPF protocol can construct an overlay network topology for logical links and physical links across these heterogeneous networks, and calculate the reachability routes of overlay network nodes based on this topology. | |||||||||||||
| draft-sheth-dns-integration-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shi-cats-analysis-of-metric-distribution-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shi-ippm-congestion-measurement-data-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shi-ippm-congestion-measurement-ipv6-options-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shi-quic-dtp-10.txt | ||||||||||||||
| Deadline-aware Transport Protocol | ||||||||||||||
|
This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery. | |||||||||||||
| draft-shi-quic-structured-connection-id-03.txt | ||||||||||||||
| Structured Connection ID Carrying Metadata | ||||||||||||||
|
This document describes a mechanism to carry the metadata in the QUIC connection ID to communicate with the intermediary. | |||||||||||||
| draft-shi-scone-rtc-requirement-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shishio-grow-isp-rfd-implement-survey-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-shytyi-spring-sr6lac-01.txt | ||||||||||||||
| Segment Routing IPv6 Locator Auto Configuration | ||||||||||||||
|
This documents provides the specification of the steps a node is expected to follow for its SRv6 Locator configuration (SR6LAC). The autoconfiguration process generates locators via the the SRv6 Duplicate Locator Detection (SR6DLD) mechanism. | |||||||||||||
| draft-sidor-pce-lsp-state-reporting-extensions-01.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-sipos-cose-gmac-kmac-00.txt | ||||||||||||||
| GMAC and KMAC for COSE and JOSE | ||||||||||||||
|
This document registers JOSE and COSE algorithm code points for using two new Message Authentication Code (MAC) algorithm families. One is the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a MAC (AES-GMAC), the other is the SHA-3-derived Keccak MAC (KMAC). | |||||||||||||
| draft-sipos-dtn-bp-sand-00.txt | ||||||||||||||
| BPv7 Secure Advertisement and Neighborhood Discovery | ||||||||||||||
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). | |||||||||||||
| draft-sl-rtgwg-far-dcn-22.txt | ||||||||||||||
| Generic Fault-Avoidance Routing Protocol for Data Center Networks | ||||||||||||||
|
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. | |||||||||||||
| draft-slevinski-iswa-2010-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-smn-idr-inter-domain-ibgp-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-smyslov-ipsecme-ikev2-cookie-revised-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-smyslov-ipsecme-ikev2-reliable-transport-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-snell-activity-streams-type-01.txt | ||||||||||||||
| The application/stream+json Media Type | ||||||||||||||
|
This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. | |||||||||||||
| draft-snijders-constraining-rpki-trust-anchors-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-soares-nmrg-green-security-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-song-ippm-ioam-ipv6-support-04.txt | ||||||||||||||
| 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, and 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. | |||||||||||||
| draft-song-lake-ra-02.txt | ||||||||||||||
| Remote attestation over EDHOC | ||||||||||||||
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. | |||||||||||||
| draft-song-mpls-flag-based-opt-04.txt | ||||||||||||||
| Flag-based MPLS Network Actions for On-Path Telemetry | ||||||||||||||
|
This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks. | |||||||||||||
| draft-song-network-aware-dns-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-song-savnet-inter-domain-bgp-ops-03.txt | ||||||||||||||
| BGP Operations for Inter-domain SAVNET | ||||||||||||||
|
This document attempts to present BGP policy-based solution for source address validation in inter-domain networks. | |||||||||||||
| draft-soni-auth-uri-01.txt | ||||||||||||||
| The auth URI scheme | ||||||||||||||
|
This document describes an URI scheme capable of susbtituting userinfo in traditional URIs, in machine-to-machine contexts, allowing for the deprecation and, in some applications, complete elimination of userinfo from URIs. In particular, the nature of the proposed URI scheme makes it unsuitable for use in semantic attacks, without compromising legitimate use-cases. | |||||||||||||
| draft-soni-http-dynamic-backpressure-00.txt | ||||||||||||||
| Dynamic Backpressure for HTTP-based systems | ||||||||||||||
|
This document describes a mechanism for introducing dynamic backpressure into an HTTP-based system, to aid in controlling server resources while minimizing tradeoffs. | |||||||||||||
| draft-soni-meta-uri-00.txt | ||||||||||||||
| Meta URIs: Generic Syntax | ||||||||||||||
|
This document describes a format for embedding a URI inside a URI, as part of a URI scheme's syntax definition. | |||||||||||||
| draft-spaghetti-sidrops-aspa-slurm-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-spinosa-urn-lex-24.txt | ||||||||||||||
| A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) | ||||||||||||||
|
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. | |||||||||||||
| draft-sr-bess-evpn-vpws-gateway-05.txt | ||||||||||||||
| Ethernet VPN Virtual Private Wire Services Gateway Solution | ||||||||||||||
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. | |||||||||||||
| draft-sriram-sidrops-asra-verification-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-stephan-green-ucs-and-reqs-01.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-stephan-legacy-path-eco-design-01.txt | ||||||||||||||
| legacy Modularity Usage for Eco-conception | ||||||||||||||
|
This document discusses the usage of inventory-maintained information for assessing the adaptation of existing devices to eco-design. This assessment is driven by the weight of the manufacturing in the sustainability cost with regard to the power consumption in operation. | |||||||||||||
| draft-stone-pce-update-open-00.txt | ||||||||||||||
| PCE Communication Protocol (PCEP) extensions for updating Open Message content | ||||||||||||||
|
This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to update information previously exchanged during PCEP session establishment via the Open message. | |||||||||||||
| draft-storey-smtp-client-id-18.txt | ||||||||||||||
| SMTP Service Extension for Client Identity | ||||||||||||||
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as SMTP authentication have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of authenticated SMTP activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the SMTP service protocol called "CLIENTID" that a SMTP client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identify verification method in a similar manner to other Multi-Factor authentication techniques. | |||||||||||||
| draft-suk-nmrg-sdaf5g-ibn-00.txt | ||||||||||||||
| Security Data Analytics Function Based on 5G Service-Based Architecture for Intent-Based Network Management | ||||||||||||||
|
This document is derived from the architecture and detailed functions of SDAF. It is a network function to perform a security analysis and provide analysis results in a 5G system with a service-based architecture (SBA). To this end, the concept of SDAF, the structure of internalizing the 5G system, and the communication interface used by SDAF are defined. It also defines the use cases that can utilize SDAF. This standard is based on the service and operation requirements for a 5G system with SBA. | |||||||||||||
| draft-sun-lamps-hybrid-scheme-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sun-nmrg-hybrid-switching-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-suyue-networkmulticonnection-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-svg-tiny-ps-abrotman-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sweet-iot-acme-06.txt | ||||||||||||||
| ACME-Based Provisioning of IoT Devices | ||||||||||||||
|
This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] 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. | |||||||||||||
| draft-sxg-mpls-mna-deterministic-latency-01.txt | ||||||||||||||
| MPLS Network Action for Deterministic Latency | ||||||||||||||
|
This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains. | |||||||||||||
| draft-tahiliani-tsvwg-fq-pie-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tailhardat-nmop-incident-management-noria-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tan-ccamp-fgotn-yang-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tan-detnet-cap-discovery-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tan-scone-netneutrality-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tang-detnet-network-resource-scheduling-00.txt | ||||||||||||||
| Resource orchestration and scheduling of Industrial Deterministic Network and Computing | ||||||||||||||
|
Massive data processing and complex algorithm applications in the industrial Internet require a large amount of computing resources. At the same time, real-time control requirements and production safety requirements require network reliability and certainty. This draft proposes a service-oriented task process processing framework, which divides the execution process of services into two stages, namely resource orchestration of task flow and packet transmission scheduling. In order to obtain the optimal scheduling strategy, a constrained optimization problem is developed, which aims to maximize the success rate of transmission scheduling while compromising load balancing and resource utilization. In order to improve the reliability of the network, the TSN-5G converged network architecture is used to transmit data packets. | |||||||||||||
| draft-tang-ipv4plus-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-taylor-dtn-demux-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-taylor-uuid-ncname-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-aero3-21.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-dhcpv6nd-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-ipid-ext2-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-mla-25.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-omni3-23.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-templin-6man-parcels2-18.txt | ||||||||||||||
| 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 Network (DTN) link model. | |||||||||||||
| draft-templin-intarea-parcels2-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tgraf-netconf-yang-push-observation-time-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-thomson-ppm-dap-bulk-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-thomson-ppm-dap-dp-ext-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-thomson-ppm-l1-bound-sum-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-thomson-ppm-prss-00.txt | ||||||||||||||
| High Performance Pseudorandom Secret Sharing (PRSS) | ||||||||||||||
|
Pseudorandom secret sharing (PRSS) enables the generation of a large number of shared pseudorandom values from a single shared seed. This is useful in contexts where a large amount of shared randomness is needed, such as multi-party computation (MPC). | |||||||||||||
| draft-thomson-scone-train-protocol-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tiloca-ace-authcred-dtls-profile-03.txt | ||||||||||||||
| Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. | |||||||||||||
| draft-tiloca-core-oscore-discovery-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tllq-tsr-05.txt | ||||||||||||||
| Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option | ||||||||||||||
|
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. | |||||||||||||
| draft-tlmd-push-dnssd-additional-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tls-westerbaan-mldsa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tojens-dhcp-option-concat-considerations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tomar-scone-ecn-00.txt | ||||||||||||||
| SCONE Need for Defining A New On-Path Signaling Mechanism | ||||||||||||||
|
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). | |||||||||||||
| draft-tomar-scone-privacy-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tomas-openroaming-03.txt | ||||||||||||||
| WBA OpenRoaming Wireless Federation | ||||||||||||||
|
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. | |||||||||||||
| draft-tong-idr-bgp-ls-sav-rule-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tong-savnet-sav-enhanced-by-controller-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-toomim-httpbis-versions-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-touch-tcpm-tcp-syn-ext-opt-13.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-trossen-rtgwg-impact-of-dlts-04.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-tschofenig-cose-cek-hkdf-sha256-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tschofenig-cose-cwt-chain-01.txt | ||||||||||||||
| CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs) | ||||||||||||||
|
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. This specification extends this functionality to CBOR Web Tokens (CWTs). | |||||||||||||
| draft-tschofenig-jose-cose-guidance-01.txt | ||||||||||||||
| Guidance for COSE and JOSE Protocol Designers and Implementers | ||||||||||||||
|
JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) are two widely used security wrappers, which have been developed in the IETF and have intentionally been kept in sync. This document provides guidance for protocol designers developing extensions for JOSE/COSE and for implementers of JOSE/COSE libraries. Developers of application using JSON and/or JOSE should also read this document but are realistically more focused on the documentation offered by the library they are using. | |||||||||||||
| draft-tschofenig-jose-key-identifier-security-00.txt | ||||||||||||||
| Security Aspects of Key Identifiers on COSE/JOSE | ||||||||||||||
|
This document provides guidance for improving the security of JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) implementations. It emphasizes the importance of handling key identification within the header to simplify security processing and reduce risks. Recommendations are given to ensure better interoperability and security for protocol designers and implementers | |||||||||||||
| draft-tschofenig-rats-psa-token-24.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tsou-behave-ftp46-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tsou-softwire-port-set-algorithms-analysis-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tu-nmrg-blockchain-trusted-protocol-04.txt | ||||||||||||||
| A Blockchain Trusted Protocol for Intelligent Communication Network | ||||||||||||||
|
This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. | |||||||||||||
| draft-tuexen-tsvwg-rfc6083-bis-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tuexen-tsvwg-rfc6951-bis-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tuexen-tsvwg-sctp-init-fwd-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tuexen-tsvwg-sctp-multipath-28.txt | ||||||||||||||
| Load Sharing for the Stream Control Transmission Protocol (SCTP) | ||||||||||||||
|
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. | |||||||||||||
| draft-tuexen-tsvwg-sctp-ppid-frag-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tuexen-tsvwg-sctp-udp-encaps-cons-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tulshibagwale-pushpull-delivery-03.txt | ||||||||||||||
| Push And Pull Based Security Event Token (SET) Delivery | ||||||||||||||
|
In situations where a transmitter of Security Event Tokens (SETs) to a network peer is also a receiver of SETs from the same peer, it is helpful to have an efficient way of sending and receiving SETs in one HTTP transaction. Using current mechanisms such as "Push-Based Delivery of Security Event Tokens (SETs) Using HTTP" or "Poll-Based Delivery of Security Event Tokens (SETs) Using HTTP" both require two or more HTTP connections to exchange SETs between peers. In many cases, such as when using the OpenID Shared Signals Framework (SSF), the situation where each entity is both a transmitter and receiver is getting increasingly common. In addition, this specification enables the transmission and reception of multiple SETs in one HTTP connection. | |||||||||||||
| draft-tulshibagwale-saag-pushpull-delivery-02.txt | ||||||||||||||
| Push And Pull Based Security Event Token (SET) Delivery | ||||||||||||||
|
In situations where a transmitter of Security Event Tokens (SETs) to a network peer is also a receiver of SETs from the same peer, it is helpful to have an efficient way of sending and receiving SETs in one HTTP transaction. In many cases, such as when using the OpenID Shared Signals Framework (SSF), the situation where each entity is both a transmitter and receiver is getting increasingly common. Using current mechanisms such as "Push-Based Delivery of Security Event Tokens (SETs) Using HTTP" or "Poll-Based Delivery of Security Event Tokens (SETs) Using HTTP" both require two or more HTTP connections to exchange SETs between peers. This is inefficient due to the latency of setting up each communication. This specification enables bi-directional transmission and reception of multiple SETs in one HTTP connection, and enables them to do so over a single HTTP or WebSocket connection. | |||||||||||||
| draft-tulshibagwale-wimse-crest-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-uralsky-gdeflate-00.txt | ||||||||||||||
| GDEFLATE bitstream specification | ||||||||||||||
|
This specification defines a lossless data compression algorithm optimized for high-throughput decompression on many-core data- parallel architectures. It is based on the original DEFLATE algorithm, modifying its bit stream layout to facilitate efficient SIMD decoding of the bitstream. | |||||||||||||
| draft-ursini-e6translate-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-uttaro-idr-bgp-oad-04.txt | ||||||||||||||
| One Administrative Domain using BGP | ||||||||||||||
|
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). | |||||||||||||
| draft-vaira-pquip-pqc-use-cases-02.txt | ||||||||||||||
| Post-quantum cryptography migration use cases | ||||||||||||||
|
This document is meant to be continuously updated, to incorporate emerging Post-Quantum Cryptography (PQC) migration use cases, with a focus on the migration from traditional signature algorithms (e.g., RSA, DSA, ECDSA) to PQC signature algorithms (e.g., LMS, XMSS, ML- DSA, SLH-DSA). This document aims at categorizing real-world scenarios based on a set of distinctive features. The primary goal is to facilitate discussions on migration strategies by offering a systematic taxonomy and a shared understanding among stakeholders. | |||||||||||||
| draft-valentinbinotto-v-verificationsystem-vv-00.txt | ||||||||||||||
| A method to store information via email and ensure the verification of the data and the identification of the version | ||||||||||||||
|
This document describes a method to store information via email and to ensure the verification of the data and identification of the version. As a long-established way of communicating and sharing information and knowledge, email is at the heart of the V verification system (V-VS). | |||||||||||||
| draft-valin-opus-scalable-quality-extension-00.txt | ||||||||||||||
| Scalable Quality Extension for the Opus Codec | ||||||||||||||
|
This document updates RFC6716 to add support for a scalable quality layer. | |||||||||||||
| draft-vandermeulen-oauth-resource-helper-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandevenne-shared-brotli-format-13.txt | ||||||||||||||
| Shared Brotli Compressed Data Format | ||||||||||||||
|
This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window and a container format to brotli (RFC 7932). Shared dictionaries and large window support allow significant compression gains compared to regular brotli. This document updates RFC 7932. | |||||||||||||
| draft-vandijk-dnsop-ds-digest-verbatim-02.txt | ||||||||||||||
| The VERBATIM Digest Algorithm for DS records | ||||||||||||||
|
The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. | |||||||||||||
| draft-vangeest-lamps-cms-euf-cma-signeddata-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-varga-detnet-mobile-latency-analysis-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-varga-detnet-srv6-data-plane-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-varga-spring-preof-sid-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-varmir-mpls-detnet-mna-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vcon-vcon-container-00.txt | ||||||||||||||
| The CDDL format for vCon - Conversation Data Container | ||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | |||||||||||||
| draft-veitch-kemeleon-00.txt | ||||||||||||||
| Kemeleon Encodings | ||||||||||||||
|
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. | |||||||||||||
| draft-venhoek-nts-pool-01.txt | ||||||||||||||
| NTS extensions for enabling pools | ||||||||||||||
|
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. | |||||||||||||
| draft-venhoek-tls-client-puzzles-00.txt | ||||||||||||||
| TLS Client Puzzles Extension | ||||||||||||||
|
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. | |||||||||||||
| draft-vesco-vcauthtls-02.txt | ||||||||||||||
| Transport Layer Security (TLS) Authentication with Verifiable Credential (VC) | ||||||||||||||
|
This document defines a new certificate type and extension for the exchange of Verifiable Credentials in the handshake of the Transport Layer Security (TLS) protocol. The new certificate type is intended to add the Verifiable Credentials as a new means of authentication. The resulting authentication process leverages a distributed ledger as the root of trust of the TLS endpoints' public keys. The endpoints can use different distributed ledger technologies to store their public keys and to perform the TLS handshake. | |||||||||||||
| draft-vesely-fix-forwarding-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-viathinksoft-oidip-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-voit-rats-trustworthy-path-routing-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-bess-mvpn-upstream-df-selection-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-cats-awareness-system-for-casfc-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-cats-green-challenges-04.txt | ||||||||||||||
| Green Challenges in Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. | |||||||||||||
| draft-wang-cats-security-considerations-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-cats-usecase-green-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-data-transmission-security-irii-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-green-framework-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-wang-hybrid-kem-ikev2-frodo-02.txt | ||||||||||||||
| 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]. ] | |||||||||||||
| draft-wang-idr-bgp-nof-nlri-01.txt | ||||||||||||||
| Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP | ||||||||||||||
|
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. | |||||||||||||
| draft-wang-idr-next-next-hop-nodes-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-iot-devices-security-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-ippm-ipv6-distributed-flow-measurement-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-ippm-ipv6-flow-measurement-07.txt | ||||||||||||||
| Flow Measurement in IPv6 Network | ||||||||||||||
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. | |||||||||||||
| draft-wang-ippm-stamp-hbh-extensions-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-lamps-root-ca-cert-rekeying-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-lsr-flex-algo-link-loss-03.txt | ||||||||||||||
| IGP Flexible Algorithm with Link Loss | ||||||||||||||
|
IGP Flexible Algorithms allow IGPs to compute constraint-based paths. Since link packet loss rate plays an important role in network evaluation, links with high packet loss rate should be bypassed during forwarding. This draft proposes a path computation method based on a maximum link loss constraint to prune unsatisfied links in Flexible Algorithms. | |||||||||||||
| draft-wang-lsr-isis-big-tlv-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-lsr-network-computing-optimization-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-open-service-access-protocol-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-pce-vlan-based-traffic-forwarding-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-ppm-ecdh-psi-00.txt | ||||||||||||||
| PSI based on ECDH | ||||||||||||||
|
This document describes Elliptic Curve Diffie-Hellman Private Set Intersection (ECDH-PSI). It instantiates the classical Meadows match-making protocol with standard elliptic curves and hash-to-curve methods. In ECDH-PSI, data items are encoded to points on an elliptic curve, and masked by the private keys of both parties. After collecting the mutually masked datasets from both parties, a participant computes their intersection and outputs the corresponding original data items as result. | |||||||||||||
| draft-wang-rtgwg-dragonfly-routing-problem-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-savnet-remote-measurement-osav-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-secure-access-of-iot-terminals-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-sidrops-fcbgp-protocol-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-sidrops-route-partial-visibility-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-tcpm-tcp-service-affinity-option-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-tvr-satellite-ip-gap-analysis-00.txt | ||||||||||||||
| Gap Analysis for IP-Based Satellite Network | ||||||||||||||
|
Satellite network are one of the TVR's use case. This document provides gap analysis on using IP for the satellite network. | |||||||||||||
| draft-wang-v6ops-industrial-translation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-warshavsky-private-features-metadata-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-watal-spring-srv6-sfc-sr-aware-functions-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-welzl-ccwg-ratelimited-increase-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-welzl-iccrg-pacing-01.txt | ||||||||||||||
| Pacing in Transport Protocols | ||||||||||||||
|
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. | |||||||||||||
| draft-welzl-panrg-oppd-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wendt-stir-certificate-transparency-04.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-wendt-stir-vesper-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-weng-ippm-srpm-path-consistency-over-srv6-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wesplaap-deleg-01.txt | ||||||||||||||
| Extensible Delegation for DNS | ||||||||||||||
|
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, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. | |||||||||||||
| draft-westerbaan-alldispatch-mpic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-westerbaan-secdispatch-mpic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-westerlund-tsvwg-sctp-dtls-chunk-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-westerlund-tsvwg-sctp-dtls-handshake-03.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-wh-rtgwg-adaptive-routing-arn-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-white-ippm-stamp-ecn-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wiethuechter-drip-det-diff-access-rdap-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wiethuechter-drip-det-moc-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wiethuechter-drip-det-registration-coap-cwt-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wiethuechter-drip-uas-sn-dns-02.txt | ||||||||||||||
| UAS Serial Numbers in DNS | ||||||||||||||
|
This document describes a way Uncrewed Aerial System (UAS) Serial Numbers are placed into and retrieved from the Domain Name System (DNS). This is to directly support DRIP-based Serial Numbers. | |||||||||||||
| draft-wiggers-hbs-state-01.txt | ||||||||||||||
| Hash-based Signatures: State and Backup Management | ||||||||||||||
|
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. | |||||||||||||
| draft-wiggers-tls-authkem-psk-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wilaw-moq-cmafpackaging-01.txt | ||||||||||||||
| CMAF Packaging for moq-transport | ||||||||||||||
|
Packaging CMAF content for use with MoQ Transport [MoQTransport] | |||||||||||||
| draft-wilton-netconf-yp-observability-00.txt | ||||||||||||||
| YANG-Push Operational Data Observability Enhancements | ||||||||||||||
|
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'. | |||||||||||||
| draft-wirtgen-bgp-tls-02.txt | ||||||||||||||
| BGP over TLS/TCP | ||||||||||||||
|
This document specifies the utilization of TCP/TLS to support BGP. | |||||||||||||
| draft-wkumari-intarea-safe-limited-domains-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wkumari-not-a-draft-21.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wkumari-rfc8110-to-ieee-02.txt | ||||||||||||||
| Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group | ||||||||||||||
|
RFC8110 describes Opportunistic Wireless Encryption (OWE), a mode that allows unauthenticated clients to connect to a network using encrypted traffic. This document transfers the ongoing maintenance and further development of the protocol to the IEEE 802.11 Working Group. This document updates RFC8110 by noting that future work on the protocol described in RFC8110 will occur in the IEEE 802.11 Working Group. | |||||||||||||
| draft-wqb-control-schedule-framework-00.txt | ||||||||||||||
| A Framework for the Control Scheduling of Network Resources | ||||||||||||||
|
This document presents a framework that elucidates various scheduling scenarios and identifies the entities involved in requesting scheduled changes of network resources or policy/action execution. It also addresses additional challenges such as conflict resolution, priority handling, and synchronization of scheduled tasks, ultimately enhancing the reliability and performance of network services. This document also describes the applicability of various network management tools and data models may be used, to meet the requirements of a set of representative use cases. | |||||||||||||
| draft-wullink-rpp-json-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-xiao-ippm-ioam-trace-extensions-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiao-mpls-lsp-ping-ioam-conf-state-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiao-nvo3-pm-geneve-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiao-rtgwg-rocev2-fast-cnp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xie-bess-evpn-extension-evn6-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xing-nmop-sdn-controller-aware-mptcp-mpquic-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiong-detnet-6man-queuing-option-06.txt | ||||||||||||||
| IPv6 Option for Scaling Deterministic Networks | ||||||||||||||
|
The DetNet-specific metadata should be carried in enhanced data plane based on the enhancement requirements in scaling deterministic networks. This document outlines how the DetNet-specific metadata are encapsulated in IPv6 [RFC8200] and specifies formats and principles for the IPv6 DetNet Options to provide deterministic services. | |||||||||||||
| draft-xiong-detnet-data-fields-edp-02.txt | ||||||||||||||
| Data Fields for DetNet Enhanced Data Plane | ||||||||||||||
|
The DetNet-specific metadata should be carried in enhanced data plane based on the enhancement requirements. This document proposes the common DetNet data fields and option types such as Aggregation Option and Deterministic Latency Option. The common DetNet Data-Fields can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. | |||||||||||||
| draft-xiong-detnet-differentiated-detnet-qos-01.txt | ||||||||||||||
| Differentiated DetNet QoS for Deterministic Services | ||||||||||||||
|
This document describes the service requirements of scaling deterministic networks and proposes Differentiated DetNet QoS (DD- QoS) for deterministic services in enhanced DetNet. | |||||||||||||
| draft-xiong-detnet-flow-aggregation-01.txt | ||||||||||||||
| Flow Aggregation for Enhanced DetNet | ||||||||||||||
|
This document describes the objectives and requirements of flow aggregation in scaling networks and proposes a scheme by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet, and suggests the flow identification of aggregated-class be used to indicate the required treatment and forwarding behaviors. Toward the end, the draft discusses how the novel flow aggregation scheme could be applied to realize the flow aggregation in a 5GS logical DetNet node participating in enhanced DetNet. | |||||||||||||
| draft-xiong-detnet-spring-srh-extensions-02.txt | ||||||||||||||
| Segment Routing Header Extensions for DetNet Data Fields | ||||||||||||||
|
The DetNet data fields such as the Deterministic Latency Option can be used in enhanced Deterministic Networking (DetNet) to provide QoS treatment to achieve deterministic latency. This document defines how DetNet data fields are encapsulated as part of the Segment Routing with IPv6 data plane (SRv6) header. | |||||||||||||
| draft-xiong-detnet-te-framework-00.txt | ||||||||||||||
| A Framework for Traffic Engineering in Enhanced DetNet | ||||||||||||||
|
Deterministic Networking (DetNet) operates at the IP layer and delivers services which provide extremely low data loss rates and bounded latency within a network domain. DetNet can be seen as a specialized branch of Traffic Engineering. There is a requirement to use DetNet to provide Quality of Service (QoS) in large-scale networks. TE can be a valuable tool to help scale DetNet. This document provides a framework for traffic engineering to achieve DetNet QoS in enhanced DetNet. It provides references to DetNet control plane and data plane enhancements that can be used to deliver DetNet traffic engineering. | |||||||||||||
| draft-xiong-green-host-power-monitoring-yang-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiong-hpwan-problem-statement-00.txt | ||||||||||||||
| 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 large volume data transmission over WANs, and it needs to ensure large-scale data processing and provide efficient transmission services. This document outlines the problems for HP-WANs. | |||||||||||||
| draft-xiong-idr-detnet-flow-mapping-06.txt | ||||||||||||||
| BGP Flow Specification for DetNet and TSN Flow Mapping | ||||||||||||||
|
This document proposes a set of extensions to BGP Flow Specification for the flow mapping of Deterministic Networking (DetNet) when interconnected with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is used for the filtering of the packets that match the DetNet networks and the mapping between TSN streams and DetNet flows in the control plane. | |||||||||||||
| draft-xiong-lsr-deterministic-link-00.txt | ||||||||||||||
| IGP Extensions for Deterministic Link | ||||||||||||||
|
This document proposes the deterministic link to provide an one- dimensional metric to indicate the deterministic forwarding capabilities at different levels and proposes the deterministic links distribution by IGP extensions. | |||||||||||||
| draft-xiong-lsr-time-resource-00.txt | ||||||||||||||
| IGP Extensions for Time-based Resource | ||||||||||||||
|
This document proposes the time-based resources and the distribution by IGP extensions for traffic engineering in control plane to simplify resource management and scheduling in certain networks requiring the latency guarantees. | |||||||||||||
| draft-xiong-nmop-host-power-monitoring-yang-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiong-pce-detnet-bounded-latency-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xiong-rtgwg-requirements-hp-wan-00.txt | ||||||||||||||
| Requirements for High-performance Wide Area Networks | ||||||||||||||
|
Many applications such as big data and intelligent computing demand massive data transmission between data centers, which needs to ensure data integrity and provide stable and efficient transmission services in wide area networks and metropolitan area networks. This document outlines the requirements for High-performance Wide Area Networks (HP-WAN). | |||||||||||||
| draft-xiong-rtgwg-use-cases-hp-wan-00.txt | ||||||||||||||
| Use Cases for High-performance Wide Area Network | ||||||||||||||
|
Big data and intelligent computing is widely adopted and in rapid development, with many applications demand massive data transmission with higher performance in wide area networks and metropolitan area networks. This document describes the use cases for High-performance Wide Area Networks (HP-WAN). | |||||||||||||
| draft-xls-intarea-evn6-00.txt | ||||||||||||||
| EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay | ||||||||||||||
|
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. | |||||||||||||
| draft-xp-ippm-detnet-stamp-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-deepspace-security-privacy-considerations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-idr-bgp-route-broker-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-idr-fare-02.txt | ||||||||||||||
| Fully Adaptive Routing Ethernet using BGP | ||||||||||||||
|
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. | |||||||||||||
| draft-xu-idr-route-target-orf-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-ipsecme-esp-in-udp-lb-13.txt | ||||||||||||||
| Encapsulating IPsec ESP in UDP for Load-balancing | ||||||||||||||
|
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. | |||||||||||||
| draft-xu-lsr-fare-03.txt | ||||||||||||||
| Fully Adaptive Routing Ethernet using LSR | ||||||||||||||
|
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. | |||||||||||||
| draft-xu-savax-control-08.txt | ||||||||||||||
| Control Plane 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. | |||||||||||||
| draft-xu-savax-data-07.txt | ||||||||||||||
| Data Plane 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 data plane of the SAVA-X mechanism. | |||||||||||||
| draft-xu-savax-protocol-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-spring-segment-twod-ip-routing-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xz-pim-flex-algo-03.txt | ||||||||||||||
| Multi-Topology in PIM | ||||||||||||||
|
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. | |||||||||||||
| draft-xzlnp-bier-ioam-08.txt | ||||||||||||||
| BIER Encapsulation for IOAM Data | ||||||||||||||
|
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header contains a bit- string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data is encapsulated in BIER header. | |||||||||||||
| draft-yan-detnet-oam-requirements-enhancement-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yan-dmm-man-14.txt | ||||||||||||||
| Mobility Capability Negotiation | ||||||||||||||
|
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. | |||||||||||||
| draft-yang-idr-sr-policy-weight-timerange-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yang-pce-pcep-over-quic-01.txt | ||||||||||||||
| PCEP over QUIC | ||||||||||||||
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. | |||||||||||||
| draft-yang-rtgwg-arn-framework-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yang-rtgwg-srv6-sfc-reliability-framework-03.txt | ||||||||||||||
| Reliability Framework for SRv6 Service Function Chaining | ||||||||||||||
|
This document describes the framework for protection of service function chains in source routing networks. | |||||||||||||
| draft-yang-spring-sid-as-source-address-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yang-spring-sr-policy-intelligent-routing-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yao-regext-epp-quic-03.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) Transport over QUIC | ||||||||||||||
|
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. | |||||||||||||
| draft-yao-tsvwg-cco-requirement-and-analysis-02.txt | ||||||||||||||
| Collective Communication Optimizations: Requirement and Analysis | ||||||||||||||
|
Gernerative AI applications depend on large scale parallel computing clusters for model training and inference. Existing implementations of collective communication in parallel computing is built on top of RDMA, the most adoptable AI transport protocol. However, One-to- Many, Many-to-One, and Many-to-Many collective operations all depend on point-to-point transport semantics of RDMA, which inevitably introduces more bandwidth occupancy and transmission overhead. Emerging approaches for collective communication optimization focus on network-assisted collective acceleration and can work compatibly with RDMA. This document analyzes different technical schemes for network-assisted collective acceleration based on RDMA, and presents the gap between these work and current IETF standards, notably iWARP. Requirements for designing new standards are proposed accordingly. | |||||||||||||
| draft-ybb-ccamp-service-path-computation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ydb-rats-cca-endorsements-00.txt | ||||||||||||||
| Arm's Confidential Computing Architecture (Arm CCA) Attestation Verifier Endorsements | ||||||||||||||
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an Arm CCA system. | |||||||||||||
| draft-ydt-ippm-alt-mark-yang-03.txt | ||||||||||||||
| A YANG Data Model for the Alternate Marking Method | ||||||||||||||
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. | |||||||||||||
| draft-ygb-ivy-passive-network-inventory-00.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-yi-cats-hierarchical-metric-distribution-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yi-cats-hybrid-solution-03.txt | ||||||||||||||
| Hybrid Computing and Network Awareness and Routing Solution for CATS | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering architecture that takes the dynamic changes of computing and network resources into account when forwarding traffic to appropriate service instances for processing. For the development of the current network, it is important to have a solution that meets different types of service requirements and can be deployed reasonably. Therefore, this document proposes a hybrid solution to provide differentiated and flexible traffic streering capabilities for different service while saving the cost of retrofitting existing network equipment. | |||||||||||||
| draft-yi-idr-bgp-fs-edge-service-metadata-03.txt | ||||||||||||||
| Distribution of Service Metadata in BGP FlowSpec | ||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST IP address. Its routes along with service metadata can be collected by a central controller. The controller may process the metadata and distribute the result to ingress routers using BGP FlowSpec. The service metadata can be used by ingress routers to make path selections not only based on the routing cost but also on the running environment of the edge services. This document describes a mechanism to distribute the information of the service routes and related service metadata using BGP FlowSpec. | |||||||||||||
| draft-yl-cats-data-model-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ymbk-opsawg-rpsl-extref-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-yn-netmod-rfc7950bis-00.txt | ||||||||||||||
| The YANG 1.1 Data Modeling Language | ||||||||||||||
|
YANG is a data modeling language used to model configuration, operational state, asynchronous notifications, and remote procedure calls (RPCs) for network management. This document describes the syntax and semantics of version 1.1 of the YANG language (YANG 1.1). YANG 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1.0 | |||||||||||||
| draft-yn-netmod-yang-xml-00.txt | ||||||||||||||
| XML Encoding of Data Modeled with YANG | ||||||||||||||
|
This document defines encoding rules for representing YANG modeled configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using XML. GitHub Information (to be removed by RFC Editor) This document is developed on GitHub (https://github.com/netmod-wg/ rfc7950bis-and-friends). If you wish to contribute, please consider opening a pull request (PR). Please see the README file for details. | |||||||||||||
| draft-yocto-dns-relative-label-02.txt | ||||||||||||||
| Relative Labels in the Domain Name System | ||||||||||||||
|
This document defines a new DNS Label Type using the Extension Mechanisms for DNS to indicate when a relative domain name is used. | |||||||||||||
| draft-yoon-ccamp-pm-streaming-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yorgos-dnsop-dry-run-dnssec-02.txt | ||||||||||||||
| dry-run DNSSEC | ||||||||||||||
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in a DS record, referred to as dry-run DS, signal to validating resolvers that dry-run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of a dry- run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. | |||||||||||||
| draft-young-md-query-21.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-young-md-query-saml-21.txt | ||||||||||||||
| 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.22. | |||||||||||||
| draft-younsi-grow-local-path-id-03.txt | ||||||||||||||
| BMP Local Path-ID | ||||||||||||||
|
Intelligence is required to track BGP paths throughout the various RIBs and VRFs of a routing platform, due to potential attribute modifications and the use of BGP multipath. This document introduces the option to identify a path within a router in order to ease correlation in monitoring. A BMPv4 TLV is defined in order to communicate this locally significant identifier in monitoring messages. | |||||||||||||
| draft-ys-savnet-use-cases-01.txt | ||||||||||||||
| SAVNET Use Cases | ||||||||||||||
|
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. | |||||||||||||
| draft-ysl-cats-metric-definition-03.txt | ||||||||||||||
| CATS Metrics Definition | ||||||||||||||
|
This document defines a set of computing metrics used for Computing- Aware Traffic Steering(CATS). 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-metric-definition. | |||||||||||||
| draft-yu-ccamp-resource-pm-yang-00.txt | ||||||||||||||
| A YANG Data Model for Resource Performance Monitoring | ||||||||||||||
|
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. | |||||||||||||
| draft-yu-ccamp-service-automation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yu-ccamp-te-fgnm-yang-01.txt | ||||||||||||||
| YANG Data Models for Transport TE FGNM Extension Model | ||||||||||||||
|
This document defines two extension YANG data models augmenting to TE topology and TE tunnel modules, based on the FGNM (Fine-Grain Network Management) requirements in transport networks. | |||||||||||||
| draft-yu-imap-client-id-13.txt | ||||||||||||||
| IMAP Service Extension for Client Identity | ||||||||||||||
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as [IMAP] have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of [IMAP] activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the [IMAP] service protocol called "CLIENTID" that an [IMAP] client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identity verification method in a similar manner to other Multi-Factor authentication techniques. | |||||||||||||
| draft-yu-tvr-source-based-time-variant-routing-00.txt | ||||||||||||||
| Source Based Time Variant Routing | ||||||||||||||
|
This document describes a source-based time variant routing methodology that can be used in a network with predicted variations. By using source-based time variant routing, the source node uses stable information (e.g. orbit of satellite) to calculate the forwarding path between source and destination nodes. The intermediate node does not need to maintain routing information, such that in case of neighbor variations (restoration, activation, change of quality, or loss), there are no routing information changes. The routing decision is done by the source node. This makes building a highly scalable network with predicted variations possible (e.g. tens of thousands of satellites). | |||||||||||||
| draft-yuan-cats-hierarchical-loop-prevention-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yuan-idr-generic-metric-cats-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yuan-rtgwg-hfc-framework-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ywj-i2inf-data-center-networking-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ywj-opsawg-i2inf-data-center-networking-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yy-hpwan-transport-gap-analysis-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zdm-tvr-applicability-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-dnsop-ns-selection-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-idr-bgp-flowspec-extension-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-idr-sr-policy-enhanced-detnet-03.txt | ||||||||||||||
| SR Policy for enhanced DetNet | ||||||||||||||
|
SR Policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied. | |||||||||||||
| draft-zhang-ippm-stamp-co-routed-path-00.txt | ||||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extension for Co-routed Bidirectional Path | ||||||||||||||
|
This document extends STAM Return Path TLV with a Co-routed Bidirectional Path flag to implement the round-trip performance measurement for specific path. | |||||||||||||
| draft-zhang-ippm-stamp-mp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-pce-enhanced-detnet-05.txt | ||||||||||||||
| PCEP for Enhanced DetNet | ||||||||||||||
|
PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane. | |||||||||||||
| draft-zhang-pce-resource-sharing-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-rats-multiverifiers-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-rtgwg-collaboration-app-net-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-rtgwg-ipv6-address-resolution-yang-00.txt | ||||||||||||||
| YANG Data Model for IPv6 Address Resolution | ||||||||||||||
|
This document defines a YANG data model to configure and manage IPv6 address resolution based on IPv6 Neighbor Discovery (ND) protocol and other related functions, including proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), and Duplicate Address Detection (DAD). | |||||||||||||
| draft-zhang-sidrops-aspa-egress-00.txt | ||||||||||||||
| ASPA-based AS_PATH Validation 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. | |||||||||||||
| draft-zhang-sidrops-vrp-aggregation-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-srv6ops-abn-mon-data-circulation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhao-detnet-enhanced-use-cases-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhao-hpwan-scenarios-deployment-00.txt | ||||||||||||||
| 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.. | |||||||||||||
| draft-zhao-nmop-network-management-agent-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhao-spring-srh-extended-srv6-policy-key-00.txt | ||||||||||||||
| The Correspondence between Packets and SRv6 Tunnels | ||||||||||||||
|
This paper defines a new extension header-SRv6 Policy Key to focusing on the problems of timeliness and accuracy of controller-aware paths in SRv6 networks. The scheme enables network nodes to report path information to the controller by adding a path unique identifier to the message header, which ensures that the controller has a real-time and accurate picture of the SR path status. Even if the SID is lost in transmission or the controller is unable to monitor it in real time and accurately. This approach aims to network availability and O&M efficiency of SDN, particularly in scenarios involving multi-path tunnel configurations and load balancing. | |||||||||||||
| draft-zhao-tsvwg-odes-gap-analysis-01.txt | ||||||||||||||
| Gap Analysis of Online Data Express Service(ODES) | ||||||||||||||
|
This document is a gap analysis of online data express delivery services, which is helpful to the design and development of online data express delivery services. | |||||||||||||
| draft-zheng-ccamp-client-pm-yang-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zheng-ccamp-client-tunnel-yang-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zheng-pisces-00.txt | ||||||||||||||
| Pisces: Real-Time Video Transport Framework | ||||||||||||||
|
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. | |||||||||||||
| draft-zhou-ippm-enhanced-alternate-marking-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhou-mpls-mna-flow-id-00.txt | ||||||||||||||
| A General Flow ID for MPLS Network Action | ||||||||||||||
|
This document specifies a general flow ID as an in-stack data item for MPLS network action. The flow ID can be used by multiple network actions which require to identify flows. | |||||||||||||
| draft-zhou-rtgwg-perceptive-routing-information-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhu-anima-lightweight-grasp-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhu-detnet-cycle-mapping-learning-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhu-gma-tsc-03.txt | ||||||||||||||
| GMA Traffic Splitting Control | ||||||||||||||
|
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. | |||||||||||||
| draft-zhu-intarea-gma-control-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhu-lsr-isis-sr-vtn-flexalgo-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zundel-spice-glue-id-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zx-neotec-net4cloud-usecase-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zzd-idr-flowspec-scheduling-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zzd-idr-sr-policy-scheduling-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zzd-spring-schedule-sr-policy-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zzhang-bier-brownfield-options-00.txt | ||||||||||||||
| BIER Brownfield Frameworks | ||||||||||||||
|
BIER is a new architecture for the forwarding and replication of multicast data packets. This document defines possible approaches to introduce BIER into networks consisting of a mixture of BFRs and non- BFRs and their respective preconditions and properties. | |||||||||||||
| draft-zzhang-dmm-mup-evolution-09.txt | ||||||||||||||
| Mobile User Plane Evolution | ||||||||||||||
|
This document describes evolution of mobile user plane in 5G, including distributed User Plane Functions (UPFs) and alternative user plane implementations that some vendors/operators are promoting without changing 3GPP architecture/signaling, and further discusses potentially integrating UPF and Access Node (AN) in 6G mobile networks. This document is not an attempt to do 3GPP work in IETF. Rather, it discusses potential integration of IETF/wireline and 3GPP/wireless technologies - first among parties who are familiar with both areas and friendly with IETF/wireline technologies. If the ideas in this document are deemed reasonable, feasible and desired among these parties, they can then be brought to 3GPP for further discussions. | |||||||||||||
| draft-zzhang-mboned-non-source-routed-sr-mcast-01.txt | ||||||||||||||
| Non-source-routed Multicast in SR Networks | ||||||||||||||
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. | |||||||||||||
| draft-zzhang-rift-multicast-02.txt | ||||||||||||||
| Multicast Routing In Fat Trees | ||||||||||||||
|
This document specifies multicast procedures with RIFT. Multicast in RIFT is similar to Bidirectional Protocol Independent Multicast (PIM- Bidir), with the Rendezvous Point Link (RP-Link) simulated by a spanning tree of some Top of Fabric (TOF) nodes and sub-TOF nodes. | |||||||||||||
| draft-zzhang-rtgwg-router-info-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zzhang-spring-microtap-segment-03.txt | ||||||||||||||
| MicroTap Segment in Segment Routing | ||||||||||||||
|
This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. | |||||||||||||
| draft-zzn-authcodesec-00.txt | ||||||||||||||
| 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. | |||||||||||||