| |
|
| |
| | Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks |
| |
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables IP packet stateless forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. These specifications describe the PASA architecture, along with PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. |
| | Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events |
| |
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8106. |
| | The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the client's public key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. |
| | EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols |
| |
|
The existing EVPN multi-homing load-balancing modes do not adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, etc. This document defines a new multi-homing mechanism to support these loop-preventing Layer-2 protocols. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| | PIM Signaling Through BIER Core |
| |
| | draft-ietf-bier-pim-signaling-13.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Hooman Bidgoli, Fengman Xu, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Consider large networks deploying traditional PIM multicast service. Typically, each portion of these large networks have their own mandates and requirements. It might be desirable to deploy BIER technology in some part of these networks to replace traditional PIM services. In such cases downstream PIM states need to be signaled over the BIER Domain toward the source. This document specifies the procedures to signal PIM Join and Prune messages through a BIER Domain using [RFC9739] , enabling the provisioning of traditional PIM services through a BIER Domain. These procedures are valid for forwarding PIM Join/Prune messages to the Source (SSM) or Rendezvous Point (ASM). |
| | CDDL Module Structure |
| |
| | draft-ietf-cbor-cddl-modules-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Carsten Bormann, Brendan Moran |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. |
| | 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. |
| | 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. |
| | Hedged ECDSA and EdDSA Signatures |
| |
|
Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. |
| | Deterministic Nonce-less Hybrid Public Key Encryption |
| |
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. |
| | Blind BBS Signatures |
| |
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. |
| | BBS per Verifier Linkability |
| |
|
The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. |
| | OSCORE-capable Proxies |
| |
|
Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. |
| | Proxy Operations for CoAP Group Communication |
| |
|
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client typically over unicast, and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. |
| | 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. |
| | EAP-FIDO |
| |
|
This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-emu-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/. |
| | 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. |
| | File-Like ICN Collections (FLIC) |
| |
| | draft-irtf-icnrg-flic-07.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Christian Tschudin, Christopher Wood, Marc Mosko, David Oran |
| | Working Group: |
Information-Centric Networking (icnrg) |
|
This document describes how to encode an application data objet into a structured _manifest_ using Information Centric Networking (ICN) data objects, creating a File-Like ICN Collection (FLIC). The manifest is an "index table" of objects that make up the manifest itself and the application data. It records the hash value (content object hash) of each item so a consumer using the manifest may request each piece by a complete hash name. The manifest is hierarchical and may be encoded into realtively small ICN objects to fit within network MTU sizes. FLIC has several methods to guide a consumer in constructing appropriate Interest names based on the manifest. It also supports encryption of the manifest data. FLIC may be used in CCNx or Named Data Networking, or other ICNs. |
| | BGP SR Policy Extensions for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. |
| | BGP Flow Specification Version 2 - for Basic IP |
| |
| | draft-ietf-idr-fsv2-ip-basic-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Sue Hares, Donald Eastlake, Jie Dong, Chaitanya Yadlapalli, Sven Maduschke |
| | Working Group: |
Inter-Domain Routing (idr) |
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. |
| | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
|
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP control plane elements generically called "DDT Nodes". Each DDT Node is configured as "authoritative" for one or more EID-Prefixes, along with the set of RLOCs for Map-Servers or "child" DDT Nodes to which more-specific EID-Prefixes are delegated. This document obsoletes RFC 8111 and updates RFC 9301. |
| | DLEP DiffServ Aware Credit Window Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-12.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. This solution document specifies In-stack network action and In-stack data specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". |
| | NETCONF Extension to support Trace Context propagation |
| |
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. |
| | RESTCONF Extension to Support Trace Context Headers |
| |
|
This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. |
| | Considerations of network/system for AI services |
| |
| | draft-irtf-nmrg-ai-deploy-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Pedro Martinez-Julia, Qin WU |
| | Working Group: |
Network Management (nmrg) |
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, AI technology is changing from running only on very high performance servers to commodity servers with small affordable hardware, including microcontrollers, low performance CPUs, and AI chipsets. This document considers how to configure the network and system in terms of AI inference service to provide AI service in a distributed manner. It also describes the points to consider in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying network-based AI services, such as self-driving vehicles and network digital twins, are described.? |
| | CoAP: Non-traditional response forms |
| |
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated. |
| | Discovery of OSCORE Groups with the CoRE Resource Directory |
| |
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. |
| | OAM for Service Programming with Segment Routing |
| |
|
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. |
| | A YANG Data Model for Client Signal Performance Monitoring |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| | 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). |
| | DC aware TE topology model |
| |
|
This document proposes the extension of the TE topology model for including information related to data center resource capabilities. |
| | A UDP-based GMA (Generic Multi-Access) Protocol |
| |
|
A device can simultaneously connect to multiple access networks, e.g., Wi-Fi, LTE, 5G, DSL, and SATCOM (Satellite Communications). It is desirable to seamlessly combine multiple connections over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built-in multi- path capabilities. This document presents a new convergence protocol for managing data traffic across multiple network paths. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations to experiment with the protocol. |
| | SMTP Enhanced Status Codes for Potentially Unwanted Mail |
| |
|
We define a method by which an SMTP receiver can immediately notify a sender that their message is suspected to be unwanted, although it may still be accepted. |
| | IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension |
| |
|
This document defines the IKEv2 Link Maximum Atomic Packet and Packet Too Big Extension to limit reassembly operations being performed by the egress security gateway. This extension enables an egress security gateway to notify its ingress counterpart that fragmentation is happening or that the received (and potentially reassembled) ESP packet is too big and thus cannot be decrypted. In both cases, the egress node provides Maximum Transmission Unit (MTU) information. Such information enables the ingress node to configure appropriately its Tunnel Maximum Transmission Unit - also designated as MTU or Tunnel MTU (TMTU) - to prevent fragmentation or too big packets to be transmitted. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| | Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) |
| |
|
As operators migrate from an IPv4 core to an IPv6 core for global table routing over the internet, the need arises to be able provide routing connectivity for customers IPv4 only networks. This document provides a solution called 4Provider Edge, "4PE" that connects IPv4 islands over an IPv6-Only network. |
| | More Instant Messaging Interoperability (MIMI) Identity Concepts |
| |
|
This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. |
| | SCION Control Plane PKI |
| |
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture where the Control Plane PKI handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's Control Plane to authenticate and verify path information, and provisions SCION's trust model based on Isolation Domains. This document describes the trust model behind the SCION Control Plane PKI, including specifications of the different types of certificates and the Trust Root Configuration. It also specifies how to deploy the Control Plane PKI infrastructure. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | 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-07.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | Scenarios and Protocol Extension Requirements of a Generalized IPv6 Tunnel |
| |
|
IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Network Slicing, Alternate Marking, iOAM, DetNet etc. In some networks, the operators might want to leverage these new features but since the network system still using some lagecy encapsulations other than IPv6 (e.g. VxLAN, GRE etc.), these features are just not applicable for them. This document introduces some cases of such scenarios, and discusses the potential requirement of defining a new Generalized IPv6 Tunnel (GIP6). With GIP6, all the additional functions defined as IPv6 extension headers could be easily supported, so that the legacy encapsulations could migrate to a unified solution rather than sccaterred upgrade in each legacy technologies, which is heavy burden for the industry. Considering network devices have different capabilities of IPv6 extension header processing, this document also analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. |
| | 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. |
| | The "dereferenceable identifier" pattern |
| |
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. // The present revision -04 includes a few clarifications. |
| | the extensions of BGP-LS to carry security capabilities |
| |
|
The BGP-LS protocol is extended to carry the security capabilities of the node. The controller collects topology information, forms a topology path with security capabilities according to security requirements, and supports SRv6 path sending to execute node forwarding through programming. |
| | 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. |
| | RIFT extensions for SRv6 |
| |
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the RIFT extensions required to support Segment Routing over the IPv6 data plane (SRv6). |
| | 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-04.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | Crowd Sourced Remote ID |
| |
|
This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. |
| | Packed CBOR: Table set up by reference |
| |
|
Packed CBOR is a mechanism for transforming Concise Binary Object Representation (CBOR) data into a more compact form. This document introduces a means for setting up its tables by means of dereferenceable identifiers, and introduces a pattern of using it without sending long identifiers. |
| | Email Feedback Reports for DKIM Signers |
| |
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. |
| | IGP Flexible Algorithm with Link Loss |
| |
|
This document proposes extensions to the IGP Flexible Algorithms framework defined in [RFC9350]. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link loss measurements advertised via IS-IS [RFC8570] and OSPF [RFC7471], and defines new constraints for Flex-Algorithm path calculation. |
| | 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. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | 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). |
| | RTP Payload Format for Geometry-based Point Cloud Compression |
| |
|
This memo describes an RTP payload format for geometry-based point cloud compression (G-PCC) ([ISO.IEC.23090-9]). The RTP payload format defined in this document supports the packetization of one or more data units in an RTP packet payload and the fragmentation of a single data unit into multiple RTP packets. This memo also describes congestion control for a practical solution for the real-time streaming of point clouds. Finally, the document defines parameters that may be used to select optional features of the payload format or signal properties of the RTP stream. The parameters can be used with the Session Description Protocol (SDP). |
| | Safe(r) Limited Domains |
| |
|
Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks. |
| | Stand-in Tags for YANG-CBOR |
| |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. |
| | Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | IKEv2 support for Child SA PFS policy notification |
| |
|
This document defines the CHILD_PFS_INFO Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support exchanging the policy settings for the Perfect Forward Secrecy (PFS) and which Key Exchange (KE) method(s) setting of the initial Child SA that are expected to be used during Child SA rekey. |
| | SAVNET Use Cases |
| |
| | draft-ys-savnet-use-cases-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
1211176911910469110103, Xueyan Song, Changwang Lin, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces the use case for Source Address Validation (SAV) applied in intra-domain and inter-domain telecommunication networks. It describes the typical routing implements and possible improvements for SAV in the use cases. |
| | Light MLS |
| |
| | draft-kiefer-mls-light-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| | Working Group: |
Individual Submissions (none) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state, which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "light clients" that don't undertake these costs. A light client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a light client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| | GMA Traffic Splitting Control |
| |
| | draft-zhu-gma-tsc-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jing Zhu, Menglei Zhang, Sumit Roy |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the GMA (Generic Multi-Access) traffic splitting control algorithm. The receiving endpoint measures one- way-delay, round-trip time, and delivery rate for multiple connections and determines how a data flow is split across them. When update is needed, it will send out a control message, aka Traffic Splitting Update (TSU), to notify the transmitting endpoint of the new traffic splitting configuration. Compared to other sender-based multi-path transport protocols, e.g. MPTCP, MPQUIC, the GMA traffic splitting algorithm is receiver-based and does not require per-packet feedback, e.g. Ack. It is designed specifically to support the Generic Multi-Access (GMA) convergence protocol as introduced in [MAMS] [GMA]. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. |
| | Representing metadata annotations in YANG-CBOR |
| |
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| | Problem statements and requirements of Deterministic CATS on the Industrial Internet |
| |
|
This draft illustrates use cases of traffic steering for Industrial Internet in terms of dynamic computing and networking resource status,together with the requirements and solutions for CATS(Computing-Aware Traffic Steering).Industrial production tasks are time-sensitive, which put forward high requirements on collaboration of networks and applications. Industrial management platforms need to unify network forwarding and computing tasks at the same time. |
| | Bgp Extension for Tunnel Egress Point |
| |
|
In AI networks, flow characteristics often exhibit a low number of flows but with high bandwidth per flow, making it easy to cause network congestion when using traditional flow-level load balancing methods. Currently, the direction of traffic scheduling focuses on load sharing individual packets of the same flow, which requires sorting based on the Tunnel Egress Point information from the remote end. This document describes the method of publishing Tunnel Egress Point through the BGP protocol. |
| | Filter of Configuration Change Notifications |
| |
|
This document extends the YANG-Push notification subscription mechanism for on-change to reduce unnecessary reporting after an on- change YANG-Push notification is generated. |
| | Arm's Confidential Compute Architecture Reference Attestation Token |
| |
|
The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. |
| | Network Attestation for Secured foRwarding (NASR) Architecture |
| |
|
This document provides an architecture overview of NASR entities, interactive procedures and messages. |
| | 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. |
| | 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. |
| | Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers |
| |
|
Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ TLS 1.3. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
| | draft-liu-acme-rats-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide a Remote Attestation Evidence or Remote Attestation Result in any format supported by the Conceptual Message Wrapper. The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | Populating a list of YANG data nodes using templates |
| |
|
This document presents a modeling technique for configuring large scale devices in a compact way, when the device contains many similar data node patterns. A device here refers to any such entity that acts as a netconf server. This is realized by instructing the device to locally generate repetitive patterns of data nodes from a master copy called 'template' that is configured in the device. This approach is both convenient and efficient, as it minimizes the size of the running data store and reduces network provisioning time. It leverages existing YANG specification features and can be implemented with standard, off-the-shelf tools.The concept that is described in this draft does not aim to be a standard track document and does not cover the template solution that is currently being discussed within ietf netmod. |
| | Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness |
| |
|
When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Similarly, in some scenario a link attachement for the host may change without the host detecting it. In both cases the host does not receive any signals to trigger the network stack configuration refresh, so it may continue to use "old" addresses which are not valid for the link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC. |
| | DHCP Option Concatenation Considerations |
| |
|
DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by RFC 3396. However, this mechanism was defined to require support for all option types. This has led to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. |
| | Problem Statement about IPv6 Support for Multiple Routers,Multiple Interfaces,and Multiple Prefixes |
| |
|
This document discusses current limitations in IPv6 Stateless Address Auto-configuration (SLAAC) that prevent support for common multi- router, multi-interface, and multi-prefix scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. |
| | Current State of the Art for Routing in AI Networks |
| |
|
This document provides an overview of routing technologies that address the needs of traffic engineering and load balancing, with a focus on fast notification for example in adaptive or perceptive routing. As the scale and complexity of networks grow, these technologies are becoming increasingly important when fault tolerance and rapid convergence are critical. This document explores existing solutions from both the IETF and the broader industry, highlighting their applicability to various use cases, including AI workloads and general services that demand low-latency, fault recovery, and dynamic load distribution across data center networks and inter data center. It also offers suggestions for potential IETF initiatives to further develop and standardize these techniques. |
| | Documenting and Referencing Cryptographic Components in IETF Documents |
| |
|
This document describes the history of how cryptographic components have been documented and referenced in the IETF, such as in RFCs, Internet Drafts, and exernal sources. It also gives guidance for how such specification should happen in the future. %% (To be removed before publication as an RFC) This document is being developed in SAAG. There is a git repo for the document at https://github.com/paulehoffman/draft-paulwh-crypto-components (https://github.com/paulehoffman/draft-paulwh-crypto-components). %% |
| | Dynamic Trust Security Architecture for Distributed Service Mesh |
| |
|
This document proposes a dynamic trust security architecture based on Distributed Micro Service Communication (DMSC) to address the security risks in the communication of microservices. The DMSC architecture, by leveraging content semantic routing and decentralized control, transforms the traditional host-centric communication mode into a service-centric paradigm. Although DMSC enhances scalability and flexibility, its distributed nature introduces risks. To cope with these risks, it is necessary to consider security solutions for distributed large-scale microservice communication and ensure the security of services while minimizing the impact on the communication architecture. |
| | Improving Support for Multi-Router,Multi-Interface,and Multi-Prefix Scenarios |
| |
|
This document specifies a improvements to IPv6 Stateless Address Autoncofiguration (SLAAC) to fully support common multi-router, multi-interface, and multi-prefix scenarios. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8504, RFC 8028, and RFC 6724, such that these scenarios are properly supported by IPv6 host implementations. |
| | Power and Energy Efficiency |
| |
| | draft-pslm-poweff-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jan Lindblad, Snezana Mitrovic, Marisol Amador, Gonzalo Salgueiro |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a device YANG "dashboard" data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in the form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else. |
| | RPKI Terminology |
| |
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times beinconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. |
| | Lightweight Host Routing using LLDP |
| |
|
Link Layer Discovery Protocol (LLDP) is widely deployed today for discovery of information across network elements like routers, switches, and hosts. This document extends LLDP to allow hosts to advertise their IP prefixes to their attached routers which can then propagate the reachability of these host prefixes into routing protocols for enabling network-wide connectivity. |
| | IS-IS Extensions for Load Balancing Alternates |
| |
|
IGP normally computes the shortest paths in the network based on the IGP metric, without taking the link utilization into consideration. In network scenarios where there is link degradation or failure which causes link throughput reduction, or the volume of specific traffic flows increase dramatically, congestion can happen if only the best path is used for forwarding. This document describes IS-IS extensions for the computation of alternate traffic engineering paths which can be used for traffic load balancing when the shortest path is becoming congested. |
| | Adapting Home Routers to Congestion Control's Reactions for Consistent Low Latency |
| |
|
This document describes Confucius -- a practical queue management scheme designed for offering real-time flows with consistently low latency regardless of competition. Confucius employs an age-aware weight adjustment mechanism to slows down bandwidth adjustment to match the reaction of congestion control, so that the end host can reduce the sending rate without overshooting the network. Confucius is deployed on home routers and requires no configuration in normal Internet deployments. |
| | SPICE Use Cases in Telecom Network |
| |
|
This document describes use cases of the credential specific to the telecom network. It aims to propose benefits and scenarios regarding to introducing the credential to the telecom network, which can provide more scenarios and directions to Secure Patterns for Internet CrEdentials (SPICE) specifications. |
| | Clarifications to the DNS Ranking Data |
| |
|
This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181, and specifies directives whereby the source of the data determines for what purposes it may be used. |
| | Automatic Network Congestion Relief |
| |
|
This document introduces an automatic congestion relief mechanism based on intelligent traffic analysis and dynamic regulation. In the event of congestion caused by fiber optic failures, it can respond intelligently and self-heal in real time, ensuring the stable operation of the network. |
| | Fast Reroute based on Programmable Data Plane (PDP-FRR) |
| |
| | draft-li-fantel-pdp-frr-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Dan Li, Kaihui Gao, Shuai Wang, Li Chen, Xuesong Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces a fast reroute architecture within the programmable data plane (PDP-FRR) for enhancing network resilience through rapid failure detection and swift path migration, leveraging in-band network telemetry and source routing. Unlike traditional methods that rely on the control plane and face significant delays in rerouting, the proposed architecture utilizes a white-box modeling of the data plane to distinguish and analyze packet losses accurately, enabling immediate identification for link failures (including black- hole and gray failures). By utilizing in-band network telemetry and source routing, the proposed solution significantly reduces reroute times to a few milliseconds, offering a substantial improvement over existing practices and marking a pivotal advancement in failure tolerance. |
| | Encryption of SRv6 Function in SRv6 Network |
| |
|
This document describes an encryption mechanism for the SRv6 function in the SRv6 nodes. |
| | Requirements and Deployments for High-Speed IoV based on SRv6 |
| |
|
This document proposes a deployment scheme for high-speed IoV by utilizing CATS, IFIT, SRv6, and network slicing technologies. Requirements and problems are discussed, and a deployment scheme is described in detail. |
| | ACK Frequency Adjustment in Receiver |
| |
|
This document describes a mechanism for adjusting ACK frequency in the receiver. |
| | Synchronizing BMP Monitoring Options and State |
| |
|
This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector. |
| | Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in SR |
| |
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in Segment Routing (SR) networks. By extending existing OAM mechanisms such as ping, traceroute, Bidirectional Forwarding Detection (BFD), and Simple Two-way Active Measurement Protocol (STAMP), the proposed solution enables comprehensive NRP support in SR networks. |
| | Interface to In-Network Computing Functions (I2ICF): Problem Statement |
| |
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. |
| | A Framework for LLM-Assisted Network Management with Human-in-the-Loop |
| |
|
This document defines an interoperable framework that facilitates collaborative network management between Large Language Models (LLMs) and human operators. The proposed framework introduces enhanced telemetry module, LLM decision module and standardized interaction data models between human operators and LLM-driven systems, and workflows to enforce human oversight. The approach ensures compatibility with existing network management systems and protocols while improving automation and decision-making capabilities in network operations. |
| | A Framework for the Interface to In-Network Computing Functions (I2ICF) |
| |
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. |
| | Interfaces of In-Network Computing Functions in Data Center Networking |
| |
|
In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Computing Functions (ICF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these ICFs. This document focuses on the applicability of ICFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these ICFs. |
| | libZK: a zero-knowledge proof library |
| |
|
This document defines a technique for generating a succinct non- interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0. |
| | Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems |
| |
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) in Cooperative Intelligent Transportation Systems (C-ITS). For example, in the context of Vehicle-to-Everything (V2X) communications, efficient management of Vehicle-to-Vehicle (V2V) communications and their integration with C-ITS can greatly benefit from in-network computing. By leveraging ICFs, it becomes possible to optimize real- time communication, streamline traffic management, and enhance data processing and security services at the network edge. |
| | Source Address Validation Deployment Status |
| |
|
This document provides a summary of methods for measuring the deployment status of source address validation, with an overview of its deployment status. It reviews various methods for measuring outbound and/or inbound source address validation, including established tools like CAIDA Spoofer, as well as recently proposed remote measurement methods. By combining results from these different methods, the document offers a comprehensive overview of the status of source address validation deployment across the Internet. |
| | Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. |
| | QUIC NAT |
| |
|
QUIC uses UDP as its transport layer protocol. Many existing NAT routers rely on observing TCP SYN, ACK, and FIN packets to determine the establishment and termination of connections, thereby precisely maintaining the lifecycle of NAT mapping entries. For QUIC, NAT devices can only manage mapping entries based on ordinary UDP aging mechanisms, which may cause NAT entries for long-lived QUIC connections to be prematurely aged and re-bound, resulting in changes to source ports. This document proposes a solution that extends the IP header options field to identify QUIC connections, facilitating NAT devices that do not recognize QUIC to accurately determine the lifecycle of QUIC connections and prevent random aging and re-mapping of long-lived QUIC connections. |
| | Congestion Detection Optimization |
| |
|
This draft proposes an adaptive congestion detection mechanism for high-throughput data transmission in wide area networks (WANs). With increasing network bandwidth (up to 800Gbps) and challenges in traditional TCP-based protocols (e.g., throughput degradation over long distances and high packet loss rates), the solution focuses on optimizing congestion identification while minimizing bandwidth overhead. |
| | Default Policy and Related Metrics in CATS |
| |
|
This document describes the considerations and requirements of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). Especially, it suggests that a default policy should be supported on the Ingress, and one or more default metrics should be included in the notification. |
| | Adaptive Load Balance Enhancement |
| |
|
This draft proposes an adaptive load-balancing mechanism to address high-throughput transmission challenges in East-West computing, data exchange, and DC interconnection services. Traditional methods-ECMP, RPS, and Flowlet-face limitations: ECMP suffers from hash collisions and load imbalance; RPS risks TCP packet reordering; Flowlet depends on impractical manual thresholds for burst interval configuration, leading to suboptimal performance. |
| | SR-MPLS Aggregation Segment |
| |
|
One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. Contrary to this, MPLS forwarding works on exact match on MPLS labels. This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. This document introduces an Aggregation Segment for Segment Routing with MPLS data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks. |
| | Source Address Validation Using Source Address Authorizations (SOAs) |
| |
|
Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to validate the authenticity of source address of packets. Source Address Authorization (SOA) is a newly defined cryptographically signed object; it provides a means of recording information about the last Autonomous System (AS) traversed by packets before reaching a specific AS. When validated, the eContent of an SOA object confirms that the holder of the listed AS Number (ASN) has authorized the specified pre-ASes. This enables other ASes to collaboratively filter spoofed traffic, enhancing global Internet security by mitigating source address spoofing and DDoS attacks. |
| | Terminal Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent mobility management adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. |
| | Information Element for Flow Discard Classification |
| |
|
This document defines a new IPFIX Information Element for classifying flow-level discards which aligns with the information model defined in [I-D.ietf-opsawg-discardmodel]. The flowDiscardClass Information Element provides consistent classification of packet discards across IPFIX implementations, enabling correlation between device and interface-level statistics and impacted flows. |
| | Computing Energy Consumption Path in Segment Routing Networks |
| |
|
This document describes a method for computing energy consumption paths in Segment Routing (SR) networks, aiming to optimize network traffic routing for energy efficiency, including procedures for energy consumption data collection, path calculation, and issuance, as well as considerations for data plane implementation in both MPLS SR and SRv6 networks. |
| | PCEP extensions for energy consumption |
| |
|
[draft-liu-spring-sr-energy-consumption-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document further details the process of using the PCEP protocol for energy consumption based path requests. The Path Computation Element Communication Protocol (PCEP) provides mechanisms that enable Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs). This document describes the extension to PCEP for conveying link energy consumption and node energy consumption, allowing path computation based on these energy consumption information. |
| | Flexible Algorithms for Energy Efficiency |
| |
|
[draft-liu-spring-sr-policy-energy-efficiency-00] describes how energy consumption information is utilized for path selection in Segment Routing (SR) networks. This document elaborates on extending IGP protocols to carry energy consumption information, enabling its dissemination within the IGP domain and ultimately transmitting it to the controller. This allows the controller to perform routing calculations based on energy consumption metrics. |
| | BGP-LS extensions for energy efficiency |
| |
|
[draft-liu-spring-sr-policy-energy-efficiency-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document elaborates on extending BGP-LS to carry energy consumption information and transmit it to the controller, enabling the controller to perform routing calculations based on energy consumption metrics. |
| | Verifiable STI Persona (VESPER) Use Cases and Requirements |
| |
|
This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called VESPER (Verifiable STI PERsona). VESPER enhances STIR by incorporating a trust framework that associating a responsible business entity and/or human with the assignment and right-to-use a telephone number. Important to the use-cases and requirements are mechanisms for the preservation of privacy and explicit choice to reveal information beyond the communications service provider you have chosen to assign the telephone number with. Core to this premise is the ability to represent and prove the right to use a telephone number resource via the legitimate holder of the Vesper token. Additional metadata and attributes can be vetted and attested via vetting policies and Know- Your-Customer (KYC) processes that are not defined as part of this effort but should follow jurisdiction specific best practices and policies that may exist. The framework allows for the leveraging of trusted and identified issuers to create a signed credential known as a VESPER token that will be defined including associated claims and potential paths for extensibility in the future. In addition, transparency mechanisms are explored to provide public logs or registries of certificates, keys, entity information, or telephone number details, if desired by the telephone number holder to improve trustability, visibility and accountability within the telephone ecosystem. This document covers various scenarios in which VESPER can be used to enhance trust in communications, focusing on common real-world deployments and corresponding requirements. This work is intended to complement and align with the framework described currently as a work in progress in [I-D.wendt-stir-vesper]. |
| | RADIUS over QUIC |
| |
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. |
| | Artificial Intelligence (AI) for Network Operations |
| |
|
This document explores the role of the IETF and IRTF in advancing Artificial Intelligence for network operations (AINetOps), focusing on requirements for IETF protocols and architectures. AINetOps applies AI/ML techniques to automate and optimize network operations, enabling use cases such as reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance. The document addresses AINetOps for both single-layer IP or Optical networks and multi-layer IP/Optical networks. It defines the concept of AINetOps for networking and provides its operational benefits such as network assurance, predictive analytics, network optimization, multi-layer planning, and more. It aims to guide the evolution of IETF protocols to support AINetOps-driven network management. |
| | Extensible Delegation for DNS using different transport protocols |
| |
|
This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in [I-D.draft-wesplaap-deleg], with ability to specify transport protocols and authentication parameters supported by name servers. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec |
| |
|
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information, and. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Signaling Zone Owner Intent |
| |
|
This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines a new DNS RRtype, HSYNC (Horizontal Synchronization), that enables zone owners to designate which providers are authorized to serve and/or sign their zones, control whether providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC record allows DNS providers to discover each other and establish secure communication channels, either via DNS messages secured by SIG(0) signatures or via a RESTful API secured by TLS. This provider-to-provider communication via Agents enables automated coordination for tasks such as NS RRset management, zone transfers, and DNSSEC-related operations. This specification covers the provider discovery and communication establishment aspects. The document defines two new roles to facilitate this synchronization: the Agent responsible for provider-to-provider communication and the Combiner which merges unsigned zone data from the zone owner with managed data from providers. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in RFC8901) is an important application of this framework, the HSYNC mechanism supports broader provider synchronization needs. The specific synchronization algorithms for multi-signer operation are described in [I-D.draft-ietf-dnsop-dnssec-automation]. Specification for how to express these algorithms over provider-to- provider communication is left for a follow-up document. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Guidance for Authors writing text for the BGP Tunnel Encapsulation Attribute |
| |
|
The BGP (RFC4271) Tunnel Encapsulation Attribute (TEA) is defined in RFC9012. Currently proposed BGP specifications in the IDR and BESS Working groups have defined new tunnels and new parameters for these tunnels in Sub-TLV. The Segment Routing usage of the TEA has suggested a number of new Sub-TLVs. This document provides guidelines to help authors quickly write correct text for new tunnels (defined in tunnel TLVs) and new Sub-TLVs. These guidelines are given as "templates" to aid new authors. More experience authors should view these templates as a list of expected content. One additional challenge for tunnels using the PMSI tunnels is to carefully define the interaction between PMSI tunnels and TEA tunnels. |
| | An IETF URN Sub-Namespace for JSON Web Token Claims |
| |
|
This document establishes an IETF URN Sub-namespace for use with JSON Web Token claims. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ S/MIME. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | A reference architecture for direct presentation credential flows |
| |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. |
| | Multicast Applicability for Distributed Consensus Systems |
| |
|
This document questions the applicability of a multicast semantic for the distributed consensus problem. For this, it details the consensus problem and the solutions taken in current systems. It outlines how point-to-multipoint communication arises as part of the consensus solution. Then, it details a peer-centric realization of a permissionless approach, identifying key issues. These issues include communication costs, performance delays, and lack of finality. Hence, it discusses a multicast strawman and its expected improvements. |
| | IGMP / MLD Extension for Signaling Eco-Mode |
| |
|
This document specifies an extension to IGMPv3 and MLDv2 messages to indicate eco mode in the delivery of multicast content based on the mechanism described in [RFC9279]. |
| | Including Privacy Pass Tokens in TLS Handshakes |
| |
|
This document defines a mechanism for TLS servers to request, and TLS clients to provide, Privacy Pass tokens as part of the Encrypted Client Hello in the TLS handshake. This creates a way to add support for anonymous attestation and rate-limiting to servers that are enforcing denial-of-service protections as part of processing TLS handshakes. |
| | Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS |
| |
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
| | Public Name Masquerade for TLS Encrypted Client Hello |
| |
|
An alternative method for authenticating Encrypted Client Hello (ECH) retry configurations is described. This method enables the use of multiple public names for the same server anonymity set. |
| | ACP free "Automation Network Infrastructure" for simple in-network automation (aNI) |
| |
|
This document describes how to to build the software infrastructure for distributed automation agents using a lightweight variation of the "Autonomic Networking Infrastructure" (ANI), by using the existing ANI domain keying material (certificates and trust anchors) as well as the protocols GRASP and BRSKI protocols, but eliminating the expensive to implement "Autonomic Control Plane" (ACP) and adding proxying "Autonomic Software Agents" (ASA) instead. The resulting infrastructure is called "automation Network Infrastructure" and can be implemented solely as application level software components on routers, switches or co-located managemenet devices, avoiding the need to change any router or switches forwarding or control-plane protocols. The aNI achieves mosts of the benefits of the ANI but foregoes the ability to easily make pre-existing, insecure control-plane protocols secure or provide all the same protection against operator or SDN controller misconfigurations that the ACP provides. |
| | Composite ML-DSA Authentication in the IKEv2 |
| |
|
This draft specifies composite ML-DSA authentication in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. Namely, the authenticaiton in the IKEv2 is completed by using a compiste signature of ML-DSA [FIPS203], the newly post-quantum digital singature standard, and one of the following traditional singature algorithms, SA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. These concrete composite algorithm specifications follow [OGPKF24]. Composite ML-DSA authenticatio is achieved by asking to add a new value in the "IKEv2 Authentication Method" registry [IANA-IKEv2], mantained by IANA. After that, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate the specific composite ML-DSA algoithms. [EDNOTE: Code points for composite ML-DSA authentication may need to be assigned in the "IKEv2 Authentication Method" registry, maintained by IANA] |
| | Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) |
| |
| | draft-sajassi-bess-rfc9251-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Ali Sajassi, Mankamana Mishra, Keyur Patel, Jorge Rabadan, Wen Lin |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). This document obsoletes RFC9251 (Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)). |
| | Use Case and Challanges for the Deployment of Object-Based Media across the Internet |
| |
|
This document outlines the challenges and use cases for the deployment and operation of Object-Based Media (OBM), also known as Flexible Media (FM), across the Internet. It discusses key considerations such as compute-aware traffic steering, metric usage, bandwidth optimization, and latency reduction techniques. The intention of this document is to highlight specific challanges or areas where IETF investigation and applicable solutions are needed for the optimal deployment of OBM-based media services. |
| | Per-flow based EVPN DF Election |
| |
|
The Ethernet Virtual Private Network (EVPN) solution offers procedures for electing a Designated Forwarder (DF) for multihomed Ethernet Segments. In this context, the Provider Edge (PE) router is responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device or network. This applies in cases of an all-active multihomed Ethernet Segment (ES) as well as for BUM and unicast traffic in the case of single-active multi- homing. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the Ethernet Segment, but lacks in providing per flow based DF within the given EVPN Instances (EVIs). |
| | Staged IPv6 Transition of Domain Name Systems |
| |
|
This document specifies the three-stage IPv6 transition of Domain Name Systems (DNS) transport. The scope of this document is only the transport between authoritative servers and recursive servers, but does not include the transport of recursive servers for DNS clients. |
| | CCNx Content Versioning |
| |
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content sharing the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. |
| | SHA-3 for HPKE |
| |
|
This document defines Secure Hashing Algorithm-3 (SHA-3) options for Hybrid Public-Key Encryption (HPKE) as registered KDFs. |
| | Personal Data Portability Archive |
| |
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. |
| | Transaction Tokens |
| |
|
Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to initiate transactions with protected user identity an authorization context throughout the call chain of the workloads required to complete the request. |
| | PCAP Capture File Format |
| |
| | draft-ietf-opsawg-pcap-05.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Guy Harris, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. |
| | PCAP Next Generation (pcapng) Capture File Format |
| |
| | draft-ietf-opsawg-pcapng-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. |
| | 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 PCE 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. |
| | QUIC-LB: Generating Routable QUIC Connection IDs |
| |
|
QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. |
| | QUIC Address Discovery |
| |
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. |
| | Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) |
| |
|
This document describes extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to allow participants in a multi- hop RADIUS proxy fabric to check the status of a remote RADIUS authentication realm, gain visibility into the path that a RADIUS request will take across the RADIUS proxy fabric, and mitigate or prevent RADIUS proxy loops. |
| | Direct Anonymous Attestation for the Remote Attestation Procedures Architecture |
| |
| | draft-ietf-rats-daa-07.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Henk Birkholz, Christopher Newton, Liqun Chen, Dave Thaler |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. |
| | Inter-domain Source Address Validation (SAVNET) Architecture |
| |
|
This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. |
| | Transparent Rate Optimization for Network Endpoints (TRONE) Protocol |
| |
| | draft-thoji-scone-trone-protocol-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Standard Communication with Network Elements (scone) |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. |
| | Human Readable Validate ROA Payload Notation |
| |
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| | Human Readable ASPA Notation |
| |
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| | Path MTU (PMTU) for Segment Routing (SR) Policy |
| |
|
This document defines the Path MTU (PMTU) for Segment Routing (SR) Policy (called SR-PMTU). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU for SR Policy including the link MTU collection, the SR-PMTU computation, the SR-PMTU enforcement, and the handling behaviours on the headend. |
| | Strong Assertions of IoT Network Access Requirements |
| |
| | draft-ietf-suit-mud-10.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-21.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. |
| | IPv6-Mostly Networks: Deployment and Operations Considerations |
| |
|
This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). |
| | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. |
| |
|
| |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| | Supporting BIER in IPv6 Networks (BIERin6) |
| |
| | draft-ietf-bier-bierin6-11.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. |
| | Deterministic Networking (DetNet) Topology YANG Model |
| |
|
This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. |
| | Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members |
| |
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. |
| | YANG Data Model for OSPF SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. |
| | YANG Data Model for IS-IS SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. |
| | Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol |
| |
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. |
| | 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. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
| |
|
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality needed within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. It obsoletes RFC 6951. |
| | INIT Forwarding for the Stream Control Transmission Protocol |
| |
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
| | draft-cx-mpls-mna-inband-pm-06.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Weiqiang Cheng, Xiao Min, Rakesh Gandhi, Greg Mirsky, Giuseppe Fioccola |
| | Working Group: |
Individual Submissions (none) |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | SRv6 Context Indicator SIDs for SR-Aware Services |
| |
|
A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. |
| | Routing mechanism in Dragonfly Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing routing mechanism in dragonfly networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Payload Protocol Identifier based Fragmentation and Reassembly for the Stream Control Transmission Protocol |
| |
|
This document describes a method for the Stream Control Transmission Protocol (SCTP) allowing the upper layer to perform fragmentation, reassembly, and interleaving of large ordered user messages by using the payload protocol identifier (PPID). According to the base specification supporting fragmentation of large user messages is optional. And even if an SCTP implementation supports fragmentation, interleaving of user messages is not supported by the base specification. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | 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). |
| | Intra-domain SAVNET Support via IGP |
| |
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. |
| | Source Address Validation Enhanced by Network Controller |
| |
|
Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. |
| | Collision Free Keytags for DNSSEC |
| |
|
DNSSEC employs a Key Tag field in the RRSIG and DS resource records in order to efficiently identify the key that produced a DNSSEC signature and the key that should be used as a secure entry point into a delegated zone. The Key Tag was not intended to be a unique identifier. Key tag collisions can occur in practice for keys in the same zone, though they are relatively rare in normal operation. Colliding key tags impose additional work on a validating resolver because it then has to check signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they open up resolvers to computational denial of service attacks by adversaries deploying specially crafted zones with many intentionally colliding key tags. This document specifies updates to the DNSSEC protocol and the process of key generation to avoid colliding key tags. |
| | Secure Key Integration Protocol (SKIP) |
| |
| | draft-cisco-skip-01.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. |
| | Automation Scenarios and Requirements for Autonomous Networking (AN) Level 4 |
| |
|
This document describes a scenario of OTN-WDM service automation and collaboration in transport networks and defines related functional requirements for domain controller. |
| | Simple Time Over MoQ Protocol (STOMP) |
| |
|
This document describes Simple Time Over MoQ Protocol (STOMP), a protocol for sending the local time and, optionally, location information via Media Over QUIC Transport (MOQT) protocol [I-D.ietf-moq-transport]. Such information enables observing endpoints to measure latencies and monitor health of MOQT delivery network from different geographical locations. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | A profile for FC path attribute |
| |
|
This document specifies a mechanism for embedding a new path attribute, known as the FC path attribute, into BGP UPDATE messages. The FC (Forwarding Commitment) is a cryptographically signed object to certify an AS's routing intent on its directly connected hops. By incorporating the FC path attribute into BGP UPDATE messages, this mechanism provides enhanced route authenticity and lays the groundwork for improved data-plane forwarding verification. This mechanism is backward compatible, which means a router that supports the attribute can interoperate with a router that doesn't, allowing partial deployment across the Internet. |
| | Messaging Layer Security credentials using Selective Disclosure CBOR Web Tokens |
| |
|
The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. |
| | Yang Templates |
| |
|
Yang Templates is a way to more easily manage a network device's configuration when parts of that configuration are repetitive. This document provides a high-level description of Yang Templates, and is expected to evolve into a full solution in later versions. |
| | A Common YANG Data Model for Energy Efficiency Network Management |
| |
|
This document defines a common YANG module that is meant to be reused by various energy efficiency-related modules such as energy saving Network models, energy saving network inventory model and energy saving device models. |
| | A Network Inventory Data Model for Energy Efficiency Management |
| |
|
As a complement to the YANG Network Topology Data Model for Energy Efficiency Management, which is used for monitoring the dynamic energy consumption of network devices, this document defines YANG Network Inventory Data Model for Energy Efficiency Management that can be used for maintaining capability related energy efficiency attributes. The model provides both network view and device view of energy efficiency related inventory information. |
| | A Network Topology Data Model for Energy Efficiency Management |
| |
|
This document defines a YANG Network Topology Data Model that can be used for Energy Efficiency Management within a network. The model provides both network-centric view of energy consumption of network devices and device view of energy consumption of individual components within network devices. |
| | Credit-based Flow Control for Cross-AIDC WAN transmission Based on RSVP |
| |
|
This draft defines the Credit-based flow control mechanism for WAN based on the RSVP protocol. With the increasing demand for AI computing power, the computing power of a single AIDC can no longer meet the needs of large model training. This has given rise to cross-AIDC distributed model training, driving the demand for transmitting RoCEv2 packets over WAN networks. AI training is extremely sensitive to network packet loss, and even a small amount of packet loss may lead to a significant decline in training efficiency. In addition, the elephant flow and extreme concurrent traffic also place higher demands on network performance. Credit- based flow control is a Backpressure-based traffic management technology, which has high reliability and stability in practical applications. It can provide high-throughput and zero-packet-loss transmission guarantees for RoCEv2 traffic, effectively ensuring the efficiency of cross-data center AI training. This draft focuses on the scenario where RoCEv2 packets are transmitted through SRv6 tunnels in the WAN and further expands the capabilities of the RSVP protocol in WAN. This draft introduces the Credit-based flow control mechanism into the RSVP protocol to achieve precise traffic control and provides processing analysis. |
| | Zero Trust Network Access DM for Network Cloud Interface |
| |
|
This document defines a YANG data model for implementing Zero Trust Network Access (ZTNA) principles at the network-cloud interface. It addresses security gaps in traditional network architectures by enforcing identity-based access control, least privilege enforcement, secure exposure of resources, and continuous monitoring. The model enables real-time policy enforcement between Cloud-Aware Service Orchestrators and Network Controllers, ensuring that only authorized entities have access to specific network and cloud telemetry. |
| | Fast congestion notification for distributed RoCEv2 network based on SRv6 |
| |
| | draft-hu-rtgwg-rocev2-fcn-00.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Zehua Hu, Yongqing Zhu, Xuesong Geng, Jiayuan Hu, Tanxin Pi |
| | Working Group: |
Individual Submissions (none) |
|
AI services (e.g. distributed model training, separated storage and model training) drive the need to transmit RMDA packets through SRv6 tunnels in WAN. RoCEv2 is the most popular open standard for achieving RDMA and network offloads over ethernet, with its congestion control based on the combination of PFC and ECN. The document defines the fast congestion notification for distributed RoCEv2 network based on SRv6 tunnels, and further extends PFC and ECN to achieve precise flow control and end-to-end congestion control. |
| | PCE SR Policy Extensions for Path Scheduling |
| |
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios. This document proposes extensions to PCE SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes. |
| | Routing in Satellite Networks: Challenges & Considerations |
| |
|
The SDO 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on the satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves the significant work to be explored in the IETF domain. This draft stems from the 3GPP satellite use cases that have been studied for many years up to now, across a couple of releases, and lands on summarizing the challenges & considerations of the satellite-based routing. Based on some unique & advantageous characteristics associated with satellite networks, the draft raises briefly the general routing considerations for the integrated Non- Terrestrial & Terrestial Networks. |
| | PCEP Extension for Layer 2 (L2) Flow Specification |
| |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| | Supporting Asymmetric Links in Low Power Networks: AODV-RPL |
| |
| | draft-ietf-roll-aodv-rpl-20.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Charles Perkins, S.V.R Anand, Satish Anamalamudi, Bing Liu |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-05.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. |
| | Scalability Considerations for Network Resource Partition |
| |
| | draft-ietf-teas-nrp-scalability-07.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| | YANG Data Models for Network Resource Partitions (NRPs) |
| |
| | draft-ietf-teas-nrp-yang-03.txt |
| | Date: |
02/03/2025 |
| | 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. |