| |
|
| |
| | IPv6 is Classless |
| |
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| | The IP Geolocation HTTP Client Hint |
| |
|
Techniques that improve user privacy by hiding original client IP addresses, such as VPNs and proxies, have faced challenges with server that rely on IP addresses to determine client location. Maintaining a geographically relevant user experience requires large pools of IP addresses, which can be costly. Additionally, users often receive inaccurate geolocation results because servers rely on geo-IP feeds that can be outdated. To address these challenges, we can allow HTTP clients to actively send their network geolocation to an HTTP server via an HTTP header field. This approach will not only enhance geolocation accuracy and reduce IP costs, but it also gives clients more transparency regarding their perceived geolocation. This is also particularly useful in the case of HTTP intermediaries that hide client IP addresses, such as Oblivious HTTP (OHTTP) relays. |
| | The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. This draft is maintained the IDMEFv2 Task Force. Please consult our website for more information. https://www.idmefv2.org The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. |
| | Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. This draft is maintained the IDMEFv2 Task Force. Please consult our website for more information. https://www.idmefv2.org The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| | Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC |
| |
|
This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval. |
| | Direct Knowledge Extension to Distance Vector Routing |
| |
|
Naive Distance Vector-based routing protocols like the Routing Information Protocol [RFC_1058] suffer from a phenomena called the "count to infinity problem" in the event of a network topology change. This Internet Draft extends a naive Distance Vector routing implementation with a simple flag that allows the network to recover quickly and reliably, with no chance of routing loops to occur. 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/Sebastianmueller22/network-protocol. |
| | CoAP in Space |
| |
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. |
| | A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients |
| |
|
This document defines a standardized JSON format for automated HTTP client (e.g., web crawlers, AI bots) operators to disclose their IP address ranges publicly. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases. |
| | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path delay at each OAM transit and decapsulating nodes. The On-Path delay is defined as the delay between the OAM header encapsulating node and each OAM header transit and OAM header decapsulating nodes. This delay measurement is computed by an On-Path Telemetry protocol and is exported by the IPFIX process. |
| | 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. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses |
| |
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. |
| | Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 |
| |
|
This document describes a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. |
| |
|
| |
| | Clarifying SRv6 SID List Processing |
| |
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. Segments are indicated by Segment Identifiers (SIDs). SRv6 utilizes the Segment Routing Header (SRH), an IPv6 extension header, that includes a SID list indicating the sequence of segments and any additional processing to be performed. This document updates RFC 8754 by clarifying the processing of SID list entries. It does not change any elements of the SRv6 architecture. |
| | BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover |
| |
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. |
| | YANG Semantic Versioning |
| |
| | draft-ietf-netmod-yang-semver-24.txt |
| | Date: |
29/09/2025 |
| | Authors: |
Joe Clarke, Robert Wilton, Reshad Rahman, Balazs Lengyel, Jason Sterne, Benoit Claise |
| | Working Group: |
Network Modeling (netmod) |
|
This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 8407bis, and 8525. |
| | Updates to OAuth 2.0 Security Best Current Practice |
| |
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. |
| | Ephemeral Compute Attestation (ECA) Protocol |
| |
| | draft-ritz-eca-00.txt |
| | Date: |
29/09/2025 |
| | Authors: |
Nathanael Ritz |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Ephemeral Compute Attestation (ECA) protocol, which enables ephemeral compute instances to prove their identity without pre-shared operational credentials. ECA uses a three-phase ceremony that cryptographically combines a public Boot Factor (a high-entropy provisioning value), a secret Instance Factor, and a dynamically released Validator Factor to establish attestation evidence. The protocol is transport-agnostic and produces Entity Attestation Tokens (EAT) for consumption by Relying Parties, such as within automated certificate issuance protocols. |
| | Static Artifact Exchange (SAE) Protocol |
| |
| | draft-ritz-sae-01.txt |
| | Date: |
29/09/2025 |
| | Authors: |
Nathanael Ritz |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Static Artifact Exchange (SAE) protocol, an asynchronous transport pattern for exchanging cryptographic artifacts between two parties via a shared, stateless repository. SAE uses a "publish-then-poll," pull-only communication model where peers use the presence and size of immutable artifacts to coordinate a sequenced exchange. By enforcing a strict set of invariants, including a prohibition on parsing arbitrary content to drive the transport's state machine, SAE is designed to minimize common attack surfaces like injection and parser vulnerabilities. The pattern is transport-agnostic and is intended for use by higher-level cryptographic protocols, like Ephemeral Compute Attestation (ECA), that require a secure, minimal channel. |
| | Ephemeral Compute Attestation (ECA) - Implementation Guide |
| |
|
This document provides implementation guidance, deployment patterns, and integration considerations for the Ephemeral Compute Attestation (ECA) protocol. It explores concrete Instance Factor patterns ranging from hardware-rooted to artifact-based approaches, documents operational experiences from prototype implementations, and describes how ECA integrates with existing identity frameworks such as ACME and SPIFFE/SPIRE. The document includes practical examples, test vectors, and architectural guidance for deploying ECA across diverse compute environments from cloud VMs to bare-metal systems. |
| | SIP Extension for Model Context Protocol (MCP) |
| |
|
This document specifies a Session Initiation Protocol (SIP) extension to advertise support for, negotiate, and carry the Model Context Protocol (MCP). It defines: (1) a new SIP option-tag ("mcp"), (2) new header fields for capability advertisement and selection, (3) Contact feature-capability parameters for registration-time discovery, and (4) the "application/mcp+json" media type. MCP payloads can be exchanged during session establishment and mid-dialog using INVITE/200 (Offer/Answer), MESSAGE, and INFO. |
| |
|
| |
| | Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | Deployment and Use of the Domain Name System(DNS) in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. |
| | Reilly Government Integrity Protocol (RGIP): DOI-Archived and Blockchain-Timestamped Framework for Permanent Public Records |
| |
|
The Reilly Government Integrity Protocol (RGIP) defines a standards-aligned method to create tamper-evident, citable public records by combining content hashing, public-blockchain anchoring, and DOI-based archival. RGIP introduces the Evidence Receipt (ER), a signed, canonicalized metadata object that binds a record’s hash, a persistent identifier (DOI), and a blockchain transaction reference. The protocol specifies formats, processing steps, and verification procedures using existing IETF and related standards. |
| |
|
| |
| | TOTP Secure Enrollment |
| |
|
This document describes a secure key exchange scheme that extends the Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment method to prevent compromise of the non-expiring TOTP key by photographic capture of the QR code or by intentional or unintentional persistence of the key string in email, SMS, or other systems outside of the TOTP authenticator system itself. |
| | PCEP over QUIC |
| |
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. |
| | DNS Catalog Zone Properties for Zone Transfers |
| |
|
This document specifies DNS Catalog Zones Properties that define the primary name servers from which specific or all member zones can transfer their associated zone, as well as properties related to zone transfers such as access control. This document also defines a groups property, for the apex of the catalog zone, as a location to assign the additional properties to certain catalog zone groups. Besides the additional properties, this document updates RFC9432 by explicitly allowing CNAMEs and DNAMEs. |
| | Unique internet user id cookie |
| |
|
Next Generation browser |
| | Potato - Reverse HTTP |
| |
|
This document defines 🥔, a suite of reversed versions of HTTP for origin servers. |
| | OAuth 2.0 External Assertion Authorization Grant |
| |
|
This document specifies a new OAuth 2.0 authorization grant type, "external assertion", identified by urn:ietf:params:oauth:grant- type:external-assertion. It enables a client to obtain an access token by presenting a verifiable JWT assertion issued by a trusted external identity provider to an authorization server. The mechanism facilitates short-lived, auditable credentials for workloads without provisioning long-lived secrets. |
| | Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets,Training,Fine-Tuning,and Inference Provenance |
| |
|
The Reilly Sentinel Protocol (RSP) specifies an interoperable, dual-layer method for establishing integrity, provenance, and auditability across the artificial intelligence (AI) lifecycle. RSP defines a Sentinel Evidence Package (SEP) that binds payload digests, provenance metadata, signatures, blockchain timestamp proofs, and resolvable identifiers (DOIs). This enables tamper-evident, independently verifiable receipts for datasets, data transformations, training jobs, checkpoints, fine-tuning runs, evaluations, and inference outputs. RSP is transport-agnostic and serializable in JSON and CBOR. It leverages existing IETF and industry building blocks, including COSE/CMS signatures, CBOR (RFC 8949), CDDL (RFC 8610), JSON (RFC 8259), and NTS-secured time (RFC 8915). Anchoring is done via append-only blockchain receipts (e.g., OpenTimestamps-style proofs) and identity/lineage is stabilized with a DOI registry. The result is an evidence-grade audit trail for regulated and safety-critical AI deployments. |
| |
|
| |
| | LISP Site External Connectivity |
| |
|
This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet/ external site destination or scale-out end point in backend data center networks of AI Infrastructure). |
| | Protocol for Transposed Transactions over HTTP |
| |
|
This document specifies the Protocol for Transposed Transactions over HTTP (PTTH), an HTTP extension that allows a backend server to establish an HTTP connection to a reverse proxy and transpose HTTP request flow. The reverse proxy then forwards incoming requests to the backend server over the transposed connection. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with virtually zero overhead. |
| | Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions |
| |
|
Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. |
| |
|
| |
| | Distribution of SR P2MP Policies and State using BGP-LS |
| |
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. |
| | Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | 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. |
| | 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. |
| |
|
| |
| | Reflexive Forwarding for CCNx and NDN Protocols |
| |
|
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. |
| | Geo-Intelligence Network Based On H3 and LISP |
| |
| | draft-ietf-lisp-nexagon-57.txt |
| | Date: |
23/09/2025 |
| | Authors: |
Sharon Barkai, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Jordi Paillisse, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
Lisp-Nexagon is a geospatial intelligence network protocol designed to support physical-world applications such as transportation, public safety, and logistics. It combines the Locator/ID Separation Protocol (LISP) with the H3 spatial indexing system to enable distributed agents to report, aggregate, and disseminate geospatial state information. |
| | Maintaining CCNx or NDN flow balance with highly variable data object sizes |
| |
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| | Centralized Anycast Gateway in Ethernet VPN(EVPN) |
| |
|
EVPN Integrated Routing and Bridging (IRB) fabrics provide a flexible and extensible method for Layer-2 and Layer-3 overlay network connectivity. [EVPN-IRB] defines operation for symmetric and asymmetric EVPN IRB using distributed anycast gateway architecture (DAG). In a DAG architecture, both bridging and first-hop routing functions for overlay subnets are located on leaf PEs, with first-hop routing provided by a distributed anycast gateway provisioned across the leaf PEs. This document describes an architecture and operation for EVPN Centralized Anycast Gateway (CAG), which allows the first- hop routing function for overlay subnets to be centralized on designated IRB GWs while the bridging function is still located on the leaf PEs. The documents also covers trade-offs of deploying a CAG as compared with DAG. It further describes operation for inter- op between CAG and DAG based EVPN-IRB network overlays. |
| | Credit-based Flow Control Based on RSVP for RDMA transmission in WAN |
| |
|
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 RDMA 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 RDMA traffic, effectively ensuring the efficiency of cross-data center AI training. This draft focuses on the scenario where RDMA 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. |
| | WIMSE Workload-to-Workload Authentication |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. |
| | WIMSE Workload-to-Workload with Workload Proof Tokens |
| |
|
This document defines a DPoP-inspired JWT-based profile for workload- to-workload authentication within the WIMSE (Workload Identity in Multi System Environments) architecture. This profile uses the Workload Identity Token (WIT) combined with a Workload Proof Token (WPT) to provide cryptographic proof of possession. The WPT is a signed JWT that demonstrates the sender's possession of the private key bound to the WIT, while also binding the authentication to the specific request context. |
| | WIMSE Workload-to-Workload with HTTP Message Signatures |
| |
|
This document defines an HTTP Message Signatures-based profile for workload-to-workload authentication within the WIMSE (Workload Identity in Multi System Environments) architecture. This profile uses the Workload Identity Token (WIT) combined with HTTP Message Signatures to provide cryptographic proof of possession and message integrity protection. The profile leverages RFC 9421 to sign HTTP requests and optionally responses, ensuring that workloads can authenticate each other and verify message integrity at the application level, particularly in environments where end-to-end TLS is not feasible due to middleboxes or other infrastructure constraints. |
| |
|
| |
| | 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. |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-20.txt |
| | Date: |
16/09/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| | UDP Speed Test Protocol for One-way IP Capacity Metric Measurement |
| |
|
This document addresses the problem of protocol support for measuring One-Way IP Capacity metrics specified by RFC 9097. The Method of Measurement discussed there requires a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This document defines the UDP Speed Test Protocol for conducting RFC 9097 and other related measurements. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-33.txt |
| | Date: |
16/09/2025 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the delay, delay variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delay and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, the application of NQB PHB to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping differentiated services (Diffserv) to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| |
|
| |
| | The eap.arpa. domain and EAP provisioning |
| |
|
This document defines the eap.arpa. domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers which use the Network Access Identifier (NAI) format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140. This document updates RFC5216 and RFC9190 to define an unauthenticated provisioning method. Those specifications suggested that such a method has possible, but they did not define how it would be done. This document also updates RFC9140 to deprecate "eap- noob.arpa", and replace it with "@noob.eap.arpa" |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-22.txt |
| | Date: |
04/09/2025 |
| | Authors: |
Rishabh Parekh, Dan Voyer, Clarence Filsfils, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. This document specifies the architecture, signaling, and procedures for SR P2MP Policies with Segment Routing over MPLS (SR- MPLS) and Segment Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct, candidate paths (CP) of an SR P2MP Policy and the instantiation of the P2MP tree instances of a candidate path using Replication segments. Additionally, it describes the required extensions for a controller to support P2MP path computation and provisioning. This document updates RFC 9524. |