| |
|
| |
| | Accumulated Metric in NHC attribute |
| |
| | draft-ietf-idr-bgp-generic-metric-00.txt |
| | Date: |
30/08/2024 |
| | Authors: |
Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, Bin Wen, Marcin Kozak, Jie Dong, Luay Jalil, Ketan Talaulikar |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC7311 describes mechanism for carrying accumulated IGP cost across BGP domains however it limits to IGP-metric only. There is a need to accumulate and propagate different types of metrics as it will aid in intent-based end-to-end path across BGP domains. This document defines BGP extensions for Generic Metric sub-types that enable different types of metrics to be accumulated and carried in BGP. This is applicable when multiple domains exchange BGP routing information. |
| | 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. |
| | Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements |
| |
|
PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. |
| | MPLS Network Action for Entropy |
| |
|
Load balancing is a powerful tool for engineering traffic across a network and has been successfully used in MPLS as described in RFC 6790, "The Use of Entropy Labels in MPLS Forwarding". With the emergence of MPLS Network Actions (MNA), there is signficant benefit in being able to invoke the same load balancing capabilities within the more general MNA infrastructure. This document describes a network action for entropy to be used in conjunction with "MPLS Network Action (MNA) Sub-Stack Solution". |
| | The Restatement Anti-Pattern |
| |
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. |
| | A Routing Architecture for Satellite Networks |
| |
|
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms, enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. |
| | SRv6 Service Benchmarking Guideline |
| |
|
This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. |
| | Secure Key Integration Protocol (SKIP) |
| |
| | draft-cisco-skip-00.txt |
| | Date: |
30/08/2024 |
| | Authors: |
Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. |
| | Internet Relay Chat Protocol version 3 |
| |
|
This document describes version 3 of the Internet Relay Chat (IRC) protocol, which extends the original IRC protocol to include support for audio and video capabilities. It defines new message types, commands, and channel modes that allow for the transmission of audio and video data within the existing IRC framework, while maintaining backward compatibility with text-only clients and servers. |
| |
|
| |
| | YANG Data Models for requesting Path Computation in WDM Optical Networks |
| |
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| | Passive DNS - Common Output Format |
| |
|
This document describes a common output format of Passive DNS servers that clients can query. The output format description also includes a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. |
| | Signaling Composite Candidate Path of SR Policy using BGP-LS |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. |
| | Security for the NFSv4 Protocols |
| |
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the use of Access Control Lists, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881, |
| | Managing CBOR codepoints in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | 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. |
| | Advertisement of SR Policy Flexible Candidate Path Selection Result using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the result of SR Policy flexible candidate path selection. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. |
| | Operations,Administration and Maintenance (OAM) for Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-oam-fw-01.txt |
| | Date: |
29/08/2024 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an OAM framework for Computing-Aware Traffic Steering (CATS). The proposed OAM framework enables the fault and the performance management of end-to-end connections from clients to networks and finally to computing instances. In the following sections, the major components of the framework, the functionalities, and the deployment considerations are elaborated in detail. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-muti-dp-solution-01.txt |
| | Date: |
29/08/2024 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios. |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management on telecom and computer networks requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge graphs can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management (ITSM) Knowledge Graph (KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | QUIC Acknowledgment Frequency |
| |
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. |
| |
|
| |
| | BIER Prefix Redistribute |
| |
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| | Compression Dictionary Transport |
| |
|
This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol. |
| | Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields. |
| | Multicast YANG Data Model |
| |
|
This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | Including Additional Records for DNSSD in DNS Push Subscriptions |
| |
|
This document extends DNS Push Notifications by providing ways for DNS Push subscribers to track additional data as well as direct answers to DNS questions. This is analogous to the support for additional data specified for multicast DNS, for example. |
| | Stateless Reverse Traceroute |
| |
|
Only very few troubleshooting tools exist, that universally work on the public internet. Ping and traceroute are the ones that are most frequently used, when issues arise that are outside the user's administrative reach. Both perform quite basic checks. Ping can only confirm basic reachability of an interface. Traceroute can enumerate routers in the forward direction of a path but remains blind to the reverse path. In this memo, ICMP extensions are defined, that allow to build a reverse traceroute tool for the public internet without having to store state on the host performing the actual reverse traceroute operation. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing |
| |
|
Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. |
| |
|
| |
| | Matroska Media Container Control Track Specifications |
| |
| | draft-ietf-cellar-control-05.txt |
| | Date: |
27/08/2024 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Control Track usage found in the Matroska container. |
| | Matroska Media Container Chapter Codecs Specifications |
| |
|
This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. |
| | Initializing a DNS Resolver with Priming Queries |
| |
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. See Appendix A for the list of changes from RFC 8109. |
| | Performance-based BGP Routing Mechanism |
| |
|
The current BGP specification doesn't use network performance metrics (e.g., network latency) in the route selection decision process. This document describes a performance-based BGP routing mechanism in which network latency metric is taken as one of the route selection criteria. This routing mechanism is useful for those server providers with global reach to deliver low-latency network connectivity services to their customers. |
| | Deprecation of AS_SET and AS_CONFED_SET in BGP |
| |
|
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472. |
| | A Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
| | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
| | draft-ietf-lisp-rfc6831bis-00.txt |
| | Date: |
27/08/2024 |
| | Authors: |
Dino Farinacci, David Meyer, John Zwiebel, Stig Venaas, Vengada Govindan |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610 and RFC 9165. The latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0". It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. It is intended to serve as a basis for prototypical implementations of CDDL 2.0. This document is intended to evolve over time; it might spawn specific documents and then retire or eventually be published as a roadmap document. |
| | CDDL models for some existing RFCs |
| |
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. |
| | Problem Statement,Use Cases,and Requirements of Hierarchical SFC with Segment Routing |
| |
|
Hierarchical Service Function Chaining (hSFC) is a network service chaining method that utilizes a hierarchical structure to efficiently organize and manage service function chains, enhancing network performance and scalability. This document primarily describes the use case of hSFC, which is the security resource pool. It outlines the associated problem statement and requirements for the security resource pool. The document aims to assist in identifying candidate solution architectures and solutions. |
| | 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. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) framework. |
| | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. |
| | Internet Group Management Protocol,Version 3 |
| |
|
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. It is a revised version of the specification to include clarifications and fixes for errata in RFC 3376 and is backwards compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. |
| | IANA Considerations for Internet Group Management Protocols |
| |
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols. |
| |
|
| |
| | BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
| |
| | draft-ietf-anima-brski-prm-15.txt |
| | Date: |
26/08/2024 |
| | Authors: |
Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the Key Infrastructure (e.g., domain CA). |
| | Methods for Detection and Mitigation of BGP Route Leaks |
| |
|
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. |
| | Key Transparency Architecture |
| |
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply KT to a number of common applications. |
| | BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP |
| |
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) and Segment Routing (SR) point-to- multipoint policies with SR-MPLS data plane. Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. |
| | Approaches on Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, and applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | Flag-based MPLS Network Actions for On-Path Telemetry |
| |
|
This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks. |
| | Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
| |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| | The OID Directory: A Technical Roadmap |
| |
|
This I-D outlines a series of experimental standards documents which define the abstracts of the "OID Directory": a proposed philosophy and set of procedures used to facilitate the storage and management of the "OID tree" -- in part or in whole -- within an X.500/LDAP service implementation. |
| | The OID Directory: The Schema |
| |
|
In service to the "OID Directory" I-D series, this I-D extends schema definitions for use within an implementation of the Registration Authority Directory Information Tree. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DUA |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design strategies, requirements and procedures for the client component of the OID Directory Registration Authority client/server model. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DSA |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design considerations and basic requirements for the server component of the OID Directory Registration Authority client/server model. See the RADIR I-D for a complete draft series manifest. |
| | The OID Directory: The RA DIT |
| |
|
In service to the "OID Directory" I-D series, this I-D covers design strategies and requirements relating to the Registration Authority Directory Information Tree. See the RADIR I-D for a complete draft series manifest. |
| | IPv6 Options for Congestion Measurement |
| |
|
The Congestion Measurement enables precise congestion control, aids in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document outlines how Congestion Measurement Data-Fields are encapsulated in IPv6. |
| | A Reference Implementation of Ascertaining RPKI Signed Objects to be Validated in Incremental Updates |
| |
|
This document describes a reference implementation of how an RP ascertains which RPKI signed objects that need to be validated during a transaction of RPKI incremental update from the perspective of this RP. |
| | Static Context Header Compression and Fragmentation over networks prone to disruptions |
| |
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. |
| | A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
| |
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations |
| |
|
| |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Gap Analysis,Problem Statement,and Requirements in AI Networks |
| |
|
This document provides the gap analysis of AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | A OSF Framework for Artificial Intelligence (AI) Network |
| |
|
This document describes a framework for Artificial Intelligence (AI) network, Particularly, the document identifies a set of AI network components, describes their interactions, and exemplifies the workflow of the control and data planes. |
| | Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices |
| |
| | draft-ietf-opsawg-mud-tls-18.txt |
| | Date: |
23/08/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Dan Wing, Blake Anderson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint. |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-10.txt |
| | Date: |
23/08/2024 |
| | Authors: |
Francois Clad, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |
| |
|
| |
| | TCP-AO Protection for BGP Monitoring Protocol (BMP) |
| |
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | Captive Portal API State Structure Enhancement |
| |
|
This document specifies a new key in Captive Portal API State data structure. The purpose of the new key is to allow clients to perform the client authentication without user interaction. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| |
|
| |
| | Specifying New Congestion Control Algorithms |
| |
|
This document replaces RFC 5033, which discusses the principles and guidelines for standardzing new congestion control algorithms. It seeks to ensure that proposed congestion control algorithms operate without harm and efficiently alongside other algorithms in the global Internet. It emphasizes the need for comprehensive testing and validation to prevent adverse interactions with existing flows. This document provides a framework for the development and assessment of congestion control mechanisms, promoting stability across diverse network environments. It obsoletes RFC5033 to reflect changes in the congestion control landscape. |
| | TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences |
| |
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as- a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology in the way that it makes content distribution more accessible to more people by dramatically reducing the costs of replication. |
| | Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305 |
| |
|
This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. |
| | TLS 1.2 Update for Long-term Support |
| |
|
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | WebRTC-HTTP ingestion protocol (WHIP) |
| |
| | draft-ietf-wish-whip-16.txt |
| | Date: |
21/08/2024 |
| | Authors: |
Sergio Murillo, Alex Gouaillard |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This document updates RFC 8842 and RFC 8840. |
| |
|
| |
| | Explicit Forged Answer Signal |
| |
|
This document describes about the forged answer provided by recursive resolver. Client could protect user on security and privacy more efficiently if recursive resolver gives explict signal in the forged answer. |
| | Signaling Aggregate Header Size Limit via IGP |
| |
|
This document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node to for efficient packet processing. Aggregate header limit is the total header size(e.g, in IPv6, it includes the IPv6 header chain as well as any headers that are part of network encapsulation that precedes the innermost transport layer) that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis respecification effort for NFv4.1. It describes the structure and function of Access Control Lists within all existing minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. [Consensus Needed (Item #117a)]: Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was originally intended, this document clarifies the status of draft POSIX ACLs, with the expectation that support for these might be provided via a later extension. In addition, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. [Consensus Needed (Item #117a)]: In this document, the relationship among the multiple ACL models supported has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now-withdrawn draft POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft POSIX ACL model are considered as OPTIONAL extensions to that core, with the latter not yet present in NFsv4.1. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Updating the NTP Registries |
| |
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries, and makes updates where necessary. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. |
| | Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses |
| |
| | draft-ietf-sipcore-rfc7976bis-00.txt |
| | Date: |
20/08/2024 |
| | Authors: |
Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske |
| | Working Group: |
Session Initiation Protocol Core (sipcore) |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
| |
|
| |
| | YANG Module for BGP Communities |
| |
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardised format. |
| | PCE Communication Protocol (PCEP) extensions for updating Open Message content |
| |
|
This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to update information previously exchanged during PCEP session establishment via the Open message. |
| | Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices |
| |
|
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| |
|
| |
| | LISP Control-Plane ECDSA Authentication and Authorization |
| |
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. |
| | Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. |
| | Some pseudonymous privacy flows for More Instant Messaging Interoperability (MIMI) |
| |
|
The MIMI protocol has a baseline level of metadata privacy, which can be made more private through the optional use of per-room pseudonyms. This document describes three of many possible flows that use pseudonyms for enhanced privacy. It also discusses some ways that spam and abuse prevention mechanisms can work in conjunction with pseudonyms. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. Each path is specified as a set of "segments" encoded in the header of each packet as a list of Segment Identifiers (SIDs). This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in the SRv6 (SR in IPv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID allocation and distribution. |
| |
|
| |
| | BGP EVPN Multi-Homing Extensions for Split Horizon Filtering |
| |
|
Ethernet Virtual Private Network (EVPN) is commonly used with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The multi-homing procedures in EVPN may vary based on the type of tunnel used within the EVPN Broadcast Domain. Specifically, there are two multi-homing Split Horizon procedures designed to prevent looped frames on multi-homed Customer Edge (CE) devices: the ESI Label-based procedure and the Local Bias procedure. The ESI Label-based Split Horizon is applied to MPLS-based tunnels, such as MPLSoUDP, while the Local Bias procedure is used for other tunnels, such as VXLAN. Current specifications do not allow operators to choose which Split Horizon procedure to use for tunnel encapsulations that support both methods. Examples of tunnels that may support both procedures include MPLSoGRE, MPLSoUDP, GENEVE, and SRv6. This document updates the EVPN multi-homing procedures described in RFC 8365 and RFC 7432, enabling operators to select the Split Horizon procedure that meets their specific requirements. |
| | A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) |
| |
| | draft-spinosa-urn-lex-24.txt |
| | Date: |
17/08/2024 |
| | Authors: |
PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a Uniform Resource Name (URN) Namespace Identifier for identifying, naming, assigning, and managing persistent resources in the legal domain. This specification is published to allow adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain. This specification is an independent submission to the RFC series. It is not a standard, and does not have the consensus of the IETF. |
| | Suspending Posting Rights |
| |
|
The practice for revoking and restoring posting rights is specified in RFC 3683. The discussions for revoking posting rights stirred controversy. This document specifies a procedure for suspending posting rights to all written channels of communication used for the IETF Standards Process. This document obsoletes RFC 3683. |
| | YANG Data Model for Routing in Fat Trees (RIFT) |
| |
| | draft-ietf-rift-yang-17.txt |
| | Date: |
17/08/2024 |
| | Authors: |
Zheng Zhang, Yuehua Wei, Shaowen Ma, Xufeng Liu, Bruno Rijsman |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document defines a YANG data model for the configuration and management of Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC8342. |
| |
|
| |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. |
| | BGP SR Policy Extensions for Segment List Identifier |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Support is provided for HTTP/1.1, HTTP/2, and HTTP/3. |
| | Defined-Trust Transport (DeftT) Protocol for Limited Domains |
| |
|
This document is not an Internet Standards Track specification and does not enjoy IETF consensus. It is published for examination, evaluation, and experimentation. The Defined-trust Transport (DeftT) framework is designed to provide default-deny communications for certain types of Limited Domains (RFC8799) used for Operational Technology (OT) networks and, in particular, Critical Infrastructure networking. DeftT is designed to express and enforce application- and deployment-specific integrity, authentication, access control and behavior constraints directly in its protocol modules. It enables secure and completely self-contained (e.g., no external identity servers or certificate authorities) overlay networks where credentialed members can join and leave at any time. Security is not optional and members preconfigured only with their individual cryptographically secured identities and the secured communication rules independently authenticate other members' identities and their role- and attribute-specific communications. DeftT is an integrated trust management, multi-party transport that synchronizes collections of secured information across all members of its domain. It uses a many-to-many synchronization primitive rather than source-destination send-and-acknowledgement. Packets are not routable and information only leaves its originating subnet if it is both explicitly permitted in the secured rules and there is a member element (relay) constructed to move validated information containers across subnets. DeftT provides default deny networking for closed communities with dynamic membership and a collection-based transport that is efficient on broadcast media. DeftT is part of a Defined- trust Communications approach with an example implementation available. Combined with IPv6 multicast and modern hardware-based methods for securing keys and code, it can provide a foundation for secure and efficient communications in Limited Domains, particularaly in Critical Infrastructure domains. |
| | BPv7 Secure Advertisement and Neighborhood Discovery |
| |
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). |
| |
|
| |
| | SR Policies Extensions for Network Resource Partition in BGP-LS |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). |
| | RESTCONF Client and Server Models |
| |
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-08-14 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | NETCONF Client and Server Models |
| |
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-08-14 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | Ethernet VPN Virtual Private Wire Services Gateway Solution |
| |
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. |
| | Packet Content Filter for BGP FlowSpec |
| |
|
The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filter in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address volumetric DDoS attack traffic characterized by fixed patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes ptype, otype, offset, content-length, content, and mask encoded in the Flowspec NLRI. This new filter aims to leverage network devices such as routers and switches to defend against simple volumetric DDoS attacks, reducing the overall defence cost of carrier network. |
| |
|
| |
| | Refresh-interval Independent FRR Facility Protection |
| |
|
The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. |
| | Notable CBOR Tags |
| |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | IETF Meeting Venue Requirements Review |
| |
|
Following a review of the IETF meeting venue requirements, this document proposes updates to RFC 8718 “IETF Plenary Meeting Venue Selection Process”, clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and proposes a replacement exploratory meeting process, thereby updating RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF". |
| | Multicast Source Discovery Protocol (MSDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and the SendHoldTimer_Expires event in the MSDP protocol. The implementation of SendHoldTimer helps to address the situation where the local system detects that the remote system has not processed MSDP messages but has not terminated the MSDP session. According to this document, when the SendHoldTimer expires, the local system should close the MSDP session connection, rather than relying on the remote system to initiate the session closure. This document updates RFC3618. |
| | Label Distribution Protocol (LDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires event in the LDP protocol. The implementation of SendHoldTimer helps address situations where the local system detects that the remote system has not processed LDP messages but has not terminated the LDP session. The document specifies that when the SendHoldTimer expires, the local system should close the LDP session connection, rather than solely relying on the remote system for session termination. This document updates RFC5036. |
| | Path Computation Element (PCE) Communication Protocol (PCEP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires events in the PCEP protocol. The implementation of SendHoldTimer helps address situations where a local system detects that a remote system has not terminated the PCEP session despite not processing PCEP messages. As per this document, when the SendHoldTimer expires, the local system should close the PCEP connection rather than solely relying on the remote system to terminate the session. This document provides updates to RFC5440. |
| |
|
| |
| | YANG Data Model for MPLS LSP Ping |
| |
| | draft-nainar-mpls-lsp-ping-yang-06.txt |
| | Date: |
10/08/2024 |
| | Authors: |
Nagendra Nainar, Madhan Sankaranarayanan, Jaganbabu Rajamanickam, Carlos Pignataro, Guangying Zheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. |
| | Media Handling Considerations for Wireless Networks |
| |
|
Wireless networks like 5G cellular or Wi-Fi experience significant variations in link capacity over short intervals due to wireless channel conditions, interference, or the end-user's movement. These variations in capacity take place in the order of hundreds of milliseconds and is much too fast for end-to-end congestion signaling by itself to convey the changes for an application to adapt. Media applications on the other hand demand both high throughput and low latency, and may adjust the size and quality of a stream to network bandwidth available or dynamic change in content coded. However, catering to such media flows over a radio link with rapid changes in capacity requires the buffers and congestion to be managed carefully. Wireless networks need additional information to manage radio resources optimally to maximize network utilization and application performance. This draft provides requirements on metadata about the media transported, its scalability, privacy, and other related considerations. Note: The solution in this draft will be revised to address requirements defined in [draft-kwbdgrr-tsvwg-net-collab-rqmts]. |
| | Segment Routing IPv6 Locator Auto Configuration |
| |
|
This documents provides the specification of the steps a node is expected to follow for its SRv6 Locator configuration (SR6LAC). The autoconfiguration process generates locators via the the SRv6 Duplicate Locator Detection (SR6DLD) mechanism. |
| | BGP Signaled Prefix-List For Dynamic Configuration |
| |
|
This document defines a new BGP extended community attribute, termed the "Prefix-List Community," which allows the dynamic assignment of prefixes to named prefix-lists via BGP signaling. The proposed extension enhances the configuration and operational flexibility of prefix-lists in routing policies by associating them with community attributes directly within BGP routes. |
| |
|
| |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-09.txt |
| | Date: |
09/08/2024 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. This protocol extension has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale deployment to determine the potential benefits of this approach. |
| | ACME-Based Provisioning of IoT Devices |
| |
|
This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. |
| | Designated Verifier Signatures for JOSE |
| |
|
This specification defines designated verifier signatures for JOSE and defines algorithms that use a combination of key agreement and MACs. |
| | Dynamic Backpressure for HTTP-based systems |
| |
|
This document describes a mechanism for introducing dynamic backpressure into an HTTP-based system, to aid in controlling server resources while minimizing tradeoffs. |
| |
|
| |
| | A Network Inventory Topology Model |
| |
|
This document defines a YANG model for network inventory topology to correlate the network inventory data with the general topology model to form a base underlay network, which can facilitate the mapping and correlation of the layer (e.g. Layer 2, Layer3) topology information above to the inventory data of the underlay network for agile service provisioning and network maintenance analysis. |
| | Software Version Capability for BGP |
| |
|
In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. |
| | Simple Two-Way Direct Loss Measurement Procedure |
| |
|
This document defines Simple Two-Way Direct Loss Measurement (DLM) procedure that can be used for Alternate-Marking Method for detecting accurate data packet loss in a network. Specifically, DLM probe packets are defined for both unauthenticated and authenticated modes and they are efficient for hardware-based implementation. |
| | Paths Limit for Multiple Paths in BGP |
| |
|
This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. |
| |
|
| |
| | 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. |
| | Aggregate Reports for DKIM Signers |
| |
|
This document introduces a mechanism enabling DKIM-signing domain owners to solicit aggregate reports from email receivers. Presented in an XML format, these reports possess adaptable elements conducive for integration with current and future drafts and standards like DMARCbis. They capture the evaluation outcomes of DKIM signatures, such as 'pass' or 'fail', alongside other potential data attributes. Receivers can relay these aggregate reports to destinations designated by the DKIM-signing domain holder, contingent upon their support capabilities. |
| | An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems |
| |
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. |
| | I2NSF Analytics Interface YANG Data Model for Closed-Loop Security Control in the I2NSF Framework |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-i2nsf-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. |
| | RFC Formats and Versions |
| |
|
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published. This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. |
| |
|
| |
| | The DNSCrypt protocol |
| |
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/. Source for this draft and an issue tracker can be found at https://github.com/DNSCrypt/dnscrypt-protocol. |
| | Jitter Reduction Mechanism for DetNet |
| |
|
In large-scale deterministic networks (LDN), App-flows need to span multiple deterministic network domains, and the latency in multiple domains is added together. The jitter will be increased. In order to realize the protection service function, App-flows should be transmitted on multiple paths. The delay difference in data transmission on different paths is no different from jitter in end- to-end services. Jitter generated by various factors needs to be reduced to meet business requirements. This document describes the end-to-end jitter reduction mechanism in an LDN. This mechanism can effectively control the end-to-end jitter to meet specific business needs and make the planning of multiple paths for service protection more flexible. |
| | PCAP Capture File Format |
| |
| | draft-ietf-opsawg-pcap-04.txt |
| | Date: |
04/08/2024 |
| | 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-02.txt |
| | Date: |
04/08/2024 |
| | 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. |
| |
|
| |
| | Common Format and MIME Type for Comma-Separated Values (CSV) Files |
| |
|
This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". |
| | Open Ethics Transparency Protocol |
| |
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
This document proposes extension for ICMPv6 to detect data plane failures for EVPN over SRv6. |
| | OpenPGP External Secret Keys |
| |
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem. |
| | PCEP extensions for p2mp sr policy |
| |
| | draft-ietf-pce-sr-p2mp-policy-09.txt |
| | Date: |
02/08/2024 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Saranya Rajarathinam, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| | Working Group: |
Path Computation Element (pce) |
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. |
| |
|
| |
| | A YANG Data Model for Transport Network Client Signals |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. |
| | JMAP Essential Profile |
| |
|
JMAP (RFC8620) is a generic, efficient, mobile friendly and scalable protocol that can be used for data of any type. This makes it a good fit for migrations or data portability use cases that are focusing on data import and export. However, due to its large set of features, it is also quite complex, which makes it difficult to explore new application domains in practice. The goal of this document is to provide guidelines on implementing essential parts of JMAP for a much lower entry barrier and more efficient implementation of the protocol. |
| | Common Interface Extension YANG Data Models |
| |
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| | Sub-interface VLAN YANG Data Models |
| |
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orignating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| | Remote terminal over HTTP/3 connections |
| |
|
The secure shell (SSH) traditionally offers its secure services over an insecure network using the TCP transport protocol. This document defines mechanisms to access remote terminals by running the SSH Connection protocol over HTTP/3 using Extended CONNECT. Remote terminals over HTTP/3 enables additional benefits such as the scalability offered by HTTP multiplexing, relying on TLS for secure channel establishment leveraging X.509 certificates, HTTP Authentication schemes for client and server authentication, UDP port forwarding and stronger resilience against packet injection attacks and middlebox interference. |