| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Stateless and Scalable Network Slice Identification for SRv6 |
| |
|
This document defines a stateless and scalable solution to achieve network slicing with SRv6. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | The BLAKE3 Hashing Framework |
| |
| | draft-aumasson-blake3-00.txt |
| | Date: |
22/07/2024 |
| | Authors: |
Jean-Philippe Aumasson, Samuel Neves, Jack O'Connor, Zooko Wilcox |
| | Working Group: |
Individual Submissions (none) |
|
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). |
| | 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]) |
| | 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. |
| | 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]) |
| | EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay |
| |
| | draft-xls-intarea-evn6-00.txt |
| | Date: |
22/07/2024 |
| | Authors: |
Chongfeng Xie, Xing Li, Congxiao Bao, Mark Smith, Jibin Sun |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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". |
| |
|
| |
| | Admin Interface for the OSCORE Group Manager |
| |
| | draft-ietf-ace-oscore-gm-admin-12.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
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. |
| | 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. |
| | 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. |
| | A Voucher Artifact for Bootstrapping Protocols |
| |
| | draft-ietf-anima-rfc8366bis-12.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
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. |
| | YANG Data Model for BIER Protocol |
| |
| | draft-ietf-bier-bier-yang-09.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Interconnection Intents |
| |
|
This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. |
| | 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. |
| | 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). |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | The CDDL format for vCon - Conversation Data Container |
| |
| | draft-petrie-vcon-04.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Daniel Petrie, Thomas McCarthy-Howe |
| | Working Group: |
Individual Submissions (none) |
|
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]) |
| | 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. |
| | 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. |
| | 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. |
| | One Administrative Domain using BGP |
| |
| | draft-uttaro-idr-bgp-oad-04.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). |
| | 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. |
| | 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 |
| | 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. |
| | 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. |
| | Protocol for Requesting and Sharing Views across Networks |
| |
| | draft-ramakrishna-satp-data-sharing-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy |
| | Working Group: |
Individual Submissions (none) |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. |
| | 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. |
| | AI-Based Distributed Processing Automation in Digital Twin Network |
| |
| | draft-oh-nmrg-ai-adp-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Oh Seokbeom, Yong-Geun Hong, Joo-Sang Youn, Hyunjeong Lee, Hyun-Kook Kahng |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | RAW multidomain extensions |
| |
|
This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-path-energy-api-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Alejandro Muniz, Marisol Palmero, Fernando Munoz, Jan Lindblad |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | Asset Lifecycle Management and Operations: A Problem Statement |
| |
| | draft-palmero-ivy-ps-almo-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | Data Model for Asset Lifecycle Management and Operations |
| |
| | draft-palmero-ivy-dmalmo-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | Path Computation Based on Precision Availability Metrics |
| |
| | draft-contreras-pce-pam-03.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Luis Contreras, Fernando Agraz, Salvatore Spadaro, Quan Xiong |
| | Working Group: |
Individual Submissions (none) |
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | Use Cases and Problem Statements of Online Data Express Service |
| |
|
This document describes use cases and problem statements of Online Data Express Service. |
| | 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. |
| | 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. |
| | Discovery of Network-designated OSCORE-based Resolvers: Problem Statement |
| |
| | draft-lenders-core-dnr-03.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. |
| | 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. |
| | 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. |
| | 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. |
| | Best Practices for Protection of SRv6 Networks |
| |
|
This document describes the Best Practices for protection of Segment Routing Over IPv6 (SRv6) networks. |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | HTTP/2 AES-256 |
| |
| | draft-http2-aes256-00.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Freedman, Larry Stark, Justin Oliver |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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 |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | RTP payload format for APV |
| |
| | draft-lim-rtp-apv-00.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Individual Submissions (none) |
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APC) codec. |
| | 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. |
| | 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. |
| | SCION Deployment Issues |
| |
|
TODO Abstract here |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-06.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | SCITT Reference APIs |
| |
| | draft-ietf-scitt-scrapi-02.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Henk Birkholz, Orie Steele, Jon Geater |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
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. |
| | Structured Email |
| |
|
This document specifies how a machine-readable version of the content of email messages can be added to those messages. |
| | 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. |
| | 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. |
| | Strong Assertions of IoT Network Access Requirements |
| |
| | draft-ietf-suit-mud-09.txt |
| | Date: |
08/07/2024 |
| | Authors: |
Brendan Moran, Hannes Tschofenig |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
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. |
| |
|
| |
| | Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| | draft-ietf-ace-pubsub-profile-10.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Francesca Palombini, Cigdem Sengul, Marco Tiloca |
| | Working Group: |
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. |
| | Framework and Data Model for OTN Network Slicing |
| |
| | draft-ietf-ccamp-yang-otn-slicing-07.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
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. |
| | 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. |
| | 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. |
| | PCEP Extension for Distribution of Link-State and TE Information for Optical Networks |
| |
| | draft-lee-pce-pcep-ls-optical-14.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Yang Zhao, Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin Yoon |
| | Working Group: |
Individual Submissions (none) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | BGP over QUIC |
| |
| | draft-retana-idr-bgp-quic-05.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | A YANG Data Model for Resource Performance Monitoring |
| |
| | draft-yu-ccamp-resource-pm-yang-00.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, Mingshuang Jin |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. |
| | A YANG Data Model for Service Path Computation |
| |
|
This document defines a YANG data model for client signal service's path computation and path management. |
| | 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]. |
| | 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). |
| | 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. |
| | BGP Prefix Independent Convergence |
| |
| | draft-ietf-rtgwg-bgp-pic-21.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
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. |
| | 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. |
| | YANG Data Model for Layer 3 TE Topologies |
| |
| | draft-ietf-teas-yang-l3-te-topo-18.txt |
| | Date: |
07/07/2024 |
| | Authors: |
Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Himanshu Shah, Oscar de Dios |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for layer 3 traffic engineering topologies. |
| |
|
| |
| | 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. |
| | 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. |
| | A YANG model to manage the optical interface parameters for an external transponder in a WDM network |
| |
| | draft-ietf-ccamp-dwdm-if-param-yang-11.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
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. |
| | 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. |
| | 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". |
| | 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. |
| | YANG Data Model for Maximum SID Depth Types and MPLS Maximum SID Depth |
| |
| | draft-ietf-mpls-msd-yang-12.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Yingzhen Qu, Acee Lindem, Stephane Litkowski, Jeff Tantsura |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
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. |
| | 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. |
| | Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
| |
| | draft-eckert-detnet-tcqf-06.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren, Fan Yang |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | MicroTap Segment in Segment Routing |
| |
| | draft-zzhang-spring-microtap-segment-03.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Zhaohui Zhang, Ryan Hoffman, Gurminderjit Bajwa, Dan Voyer, Shay Zadok, Aijun Wang, Luay Jalil, Li, Siva Sivabalan |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. |
| | 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. |
| | Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
| |
| | draft-eckert-detnet-glbf-03.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | Inband Telemetry for HPCC++ |
| |
| | draft-miao-ccwg-hpcc-info-03.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Rui Miao, Surendra Anubolu, Rong Pan, Jeongkeun Lee, Barak Gafni, Jeff Tantsura, Allister Alemania, Yuval Shpigelman |
| | Working Group: |
Individual Submissions (none) |
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | SRv6 Deployment and Operation Problem Summary |
| |
| | draft-liu-srv6ops-problem-summary-03.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Yisong Liu, Dan Voyer, Thomas Graf, Zoltan Miklos, Luis Contreras, Nicolai Leymann, Linjian Song, Satoru Matsushima, Chongfeng Xie, Xinxin Yi |
| | Working Group: |
Individual Submissions (none) |
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. |
| | 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. |
| | 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. |
| | An Approach to Expose 'Device Models'-as-'Network Models' |
| |
| | draft-ovmd-netmod-dmanm-00.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Oscar de Dios, Victor Lopez, Mohamed Boucadair, Daniele Ceccarelli |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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. |
| | 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. |
| | 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. |
| | Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT |
| |
| | draft-ietf-pce-pcep-ifit-05.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola |
| | Working Group: |
Path Computation Element (pce) |
|
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. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-12.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-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. |
| | YANG Data Models for Network Resource Partitions (NRPs) |
| |
| | draft-ietf-teas-nrp-yang-02.txt |
| | Date: |
05/07/2024 |
| | Authors: |
Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
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. |